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In a peacetime environment of increasing budget cuts 
resulting in reduced manning levels, active management of 
limited manpower assets is vital to ensure mission 
accomplishment and battle readiness. Manpower analysis is 
the process by which an activity's manpower assets are 
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determine strengths and weaknesses in manning structure. 

Manpower analysis must be performed on a continual basis 
at all Naval activities. Each command must identify, 
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take appropriate actions to alleviate them. 
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I. 



INTRODUCTION 



A. BACKGROUND 

Manpower end-strengths, both military and civilian, for 
the Department of the Navy, are authorized annually by 
Congress and reflected in the Secretary of Defense's 
(SECDEF) Six Year Defense Program (SYDP) . Identification of 
future manpower requirements is an integral part of the 
Planning, Programming, and Budgeting System (PPBS) process. 
Manpower requirements are determined by force structure, 
weapons systems configurations, warfare tasking and support 
thereof . 

In a peacetime environment of increasing budget cuts 
resulting in reduced manning levels, it is vital that 
limited manpower assets be actively managed to ensure 
mission accomplishment and battle readiness. Manpower 
analysis is the process by which an activity's personnel 
assets are matched to or balanced against authorized billets 
to determine strengths and weaknesses in manning structure. 

The activity commander must be aware, at all times, of 
how his/her manning structure (personnel assigned) balances 
against the activity's billet structure (job organization). 
Manpower assets must be monitored not only for current 
status but also for future required manning levels based on 
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mission requirements and operational commitments. 

Assignment of personnel to an activity normally requires 
four to seven months lead-time. Therefore, manning 
shortfalls cannot usually be relieved quickly and must be 
planned for well in advance to ensure mission readiness. 

A case/example helps illustrate this point. An 
overseas, isolated Naval activity had a billet authorization 
(BA) for a single Utilitiesman (UT2) with a critical 6104 
Naval Enlisted Classification Code (NEC) , air-conditioning 
(AC) repair. It is vital to mission accomplishment that at 
least two of the three air-conditioners for climate control 
in the computer building be operational at all times. The 
nearest available civilian contract AC repair support was 
six hours automobile drive from the activity. No other 
military support was available at a shorter distance. 

Two weeks before the assigned UT2 ' s projected rotation 
date (PRD) , the command suddenly realized they had no relief 
on board or anyone ordered in as relief. The incumbent UT2 
could not be held at the activity as his presence was 
required for onboard relief at his next duty station. 

Through intervention of their Immediate Superior in Command 
( ISIC) , the manning control staff of Commander in Chief 
Atlantic Fleet, and the Enlisted Personnel Management 
Accounting Center (EPMAC) , a relief was detailed to and 
received by the activity two days prior to the incumbent's 
departure . 
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Had this activity performed manpower analysis on, say, a 
monthly basis, they would have recognized well in advance of 
the UT2's PRD that an onboard relief was critical to mission 
accomplishment and could have solved the problem long before 
intervention by senior commands was required. 

On the other hand; if performed properly, manpower 
analysis can result in early identification and resolution 
of potential manning problems as the following case 
illustrates. This case is for a shore activity with a 
requirement for approximately a dozen Data Processors (DPs) . 
These DPs worked with a mainframe computer which was used 24 
hours a day for real-time data analysis. The computer room 
was required to be manned 24 hours a day, on a rotating 
basis, by qualified watch-standers . At least four months on 
the job training was required to qualify an individual to go 
on the watch bill. 

By conducting manpower analysis, the Division Officer 
was able to verify the readiness of his division. The 
majority of his DPs were female, limited duty personnel 
(because of pregnancy) received from ships. The remainder 
of his division were male and female permanently assigned 
petty officers and seamen. 

About the time the limited duty personnel were finished 
qualifying for watch, they were placed on restricted work 
hours by medical (precluding watch standing duties) followed 
shortly thereafter by maternity leave. Generally these 
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individuals did not return to the shore activity at the end 
of their convalescent leave, but returned to full duty 
onboard their ships, thereby limiting the number of 
qualified watch standers to the few permanent party DPs. 

Because proactive manpower analysis was performed, the 
shore activity was able to show precisely the impact on 
current and future mission readiness of this limited duty 
assignment policy. Through close work with the DP detailing 
staff at Naval Military Personnel Command (NMPC) , this 
activity was able to have the number of limited duty 
assignments to them drastically reduced and the required 
number of regular PCS DPs restored.' 

B . PROBLEM STATEMENT 

Upper echelon Navy staffs have trained personnel 
assigned specifically as manpower analysts. At the lower 
echelon staff and activity levels, however, the 
responsibility for manpower analysis falls to the Executive 
Officer, Department Heads, and Division Officers who, 
generally, have had no formal training in this process. 

Few Naval officers are formally or even informally 
trained in the manpower analysis process, yet this is a 
vital part of effective management of scarce personnel 



By policy, medical limited duty personnel are not to be 
counted against normal BA. However, this activity found that the 
quantity of onboard permanently assigned DPs was substantially 
below NMP . 
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resources. Normally, when an officer reports for duty to an 
activity, he/she receives turnover/passdown as to the 
mission of the command and division/department. This 
passdown generally includes a list of personnel assigned to 
that work area and a description of the duties each 
performs. Rarely is an officer given a copy of the 
authorized billet structure for his/her division/department 
or shown how the personnel assigned relate to that billet 
structure. 

Generally, formal manpower analysis is performed at the 
higher echelon staff levels, usually by officers assigned 
specifically as manpower analysts. If manpower analysis is 
performed at the activity level, it is usually by personnel 
who happen to use manpower analysis techniques because of 
previous work experience in that area. An activity's 
manpower analyst should have an understanding of the 
complexity of the command's operational mission and 
administrative support requirements; how the billet 
structure is determined; what quantity of billets are 
required for full mission readiness; why there is a 
difference between Billet Authorizations and Billet 
Requirements; why a specific rating mix of personnel is 
assigned; and how the number of personnel assigned is 
determined. Knowledge of each of these areas is required in 
order to perform effective manpower analysis at any activity 
level . 
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The primary problem with the current system of manpower 
analysis employed at the activity level in the Navy is that 
Manpower Analysis training is not part of the formal officer 
training program. Most junior officers (LCDR and below) do 
not know what a Manpower Authorization (MPA) is or how to 
read it. Additionally, few officers ever see an Enlisted 
Distribution Verification Report (EDVR) or Officer 
Distribution Control Report (ODCR) or Manpower Document 
until they reach the Department Head or Executive Officer 
level. Generally, only those officers assigned duties as 
manpower analysts, such as Aviation Maintenance Officers in 
aviation squadrons, are ever required to use manpower 
analysis documents in the management of their workcenter, 
division, or department. Usually officers are completely 
unaware of their authorized billet structure and rely 
strictly on the roster of personnel assigned to them in 
order to identify workcenter structure. This lack of 
knowledge of manpower analysis documents and techniques 
results in poor planning for future manning needs. Formal 
manpower analysis is often not even done at a divisional or 
departmental level. 

C. OBJECTIVES 

The general objective of this thesis is to define the 
activity level manpower analysis process and to present a 
design for an automated database for performing this 
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process. This objective will be accomplished by presenting 
a functional description of manpower analysis, fully 
defining data inputs for the analysis process, and providing 
examples of possible outputs of the system used by various 
levels of a Naval activity. It is envisioned that 
automating the manpower analysis process at the activity 
level will readily accomplish education on the importance 
and the mechanisms of the process. 

D. RESEARCH QUESTIONS 

The area of research is limited to respond to four 
questions : 

1. From a staff, organizational, and departmental 
or divisional level, what functional requirements 
must be addressed to support effective activity 
level management of manpower resources? 

2. What data elements are required to evaluate an 
activity's manpower profile? 

3 . What manpower reports are required at each 
management level of an activity to support manpower 
planning and management? 

4. What additional personnel administration areas 
can be addressed with this system and what 
modifications will be required? 
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E. SCOPE AND LIMITATIONS 

This thesis will provide background information on the 
Department of Defense/Navy (DOD/DON) manpower development 
process and a description of the documents used at the 
activity level for manpower analysis. Functional and Data 
requirements for activity level manpower analysis will be 
identified, and a logical database design presented. 

Examples of outputs and reports will also be included. 

The scope of this thesis is limited to system analysis 
and design. It does not include implementation of the 
proposed design or building of a prototype. 

F. METHODOLOGY 

Object oriented database analysis and design methodology 
will be used to define functional and data requirements and 
to present a logical database design. This methodology will 
be described in Chapter III, User Requirements. 

Functional and data requirements for this system will be 
based on the author's professional experience as a U.S. Navy 
Manpower Analyst for six and one-half years at the Echelon 
three, four, and five levels: Commander Oceanographic 

System Atlantic (primary billet - 1983-85) ; Commander 
Helicopter Tactical Wing One (1985-88) ; and Naval Air 
Station, Agana, Guam (1980-81), respectively. 
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G. ORGANIZATION OF THESIS 



This thesis is organized as follows: 

Chapter II, entitled "Manpower Management in the Navy", 
reviews the Department of Defense/Navy (DOD/DON) level 
processes for determining activity manpower requirements. 
Views of manpower from the three upper levels of management 
at an activity will be presented and the documents required 
for activity level manpower analysis will be reviewed. 
Reports generated by the manpower analysis process will be 
presented within the context of management views of 
manpower . 

Chapter III, entitled "User Requirements", reviews the 
methodology used to define data and functional requirements, 
develops the objects to be stored in the database, and 
determines the processes that create, modify and display 
these objects. Using data from several sources, a database 
is defined which contains information on personnel assigned 
to an activity and the activity's billet structure. The 
database system, once designed, will process the information 
from the database to produce a series of predefined reports 
or respond to ad hoc queries on the database. 

Chapter IV, "Design", presents the logical database 
design using Object Oriented methodology and the Relational 
Database Model. Using this methodology, objects identified 
in the previous chapter are transformed into a relational 
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diagram. Data flows and report outputs of the system are 
also specified in, Appendices C and D, respectively. 

Chapter V, entitled "Summary and Conclusions", provides 
a brief review of the previous four chapters and presents 
suggestions for alternative functionality of the system. 

Appendices A through C provide Object Diagrams, Object 
Specifications and Object Oriented Data Flow Diagrams, 
respectively, developed during the Requirements Analysis 
phase. Appendix D provides Sample Forms/Data Input/Display 
Screens and Reports designed for data input and modification 
and data output, respectively. Appendices E and F were 
developed during the design phase of this thesis and provide 
a graphic, Appendix F, and literal description of 
relationships between the Objects presented in Appendix A. 
Appendix G defines system requirements for Update, Display, 
and Control Mechanisms. Appendix H illustrates the system 
Menu Hierarchy and provides sample menus for the system. 
Appendix I provides Pseudo Code for the Menu Hierarchy as 
well as for the reports generation procedures. 
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II 



MANPOWER ANALYSIS 



Chapter I provided a brief background on the manpower 
analysis process and the importance of that process. This 
chapter reviews the Department of Defense/Navy (DOD/DON) 
level processes for determining activity manpower 
requirements. Views of manpower from the three upper levels 
of management at an activity are presented, and the 
documents required for activity level manpower analysis are 
reviewed. Reports generated by the manpower analysis 
process are presented within the context of management views 
of manpower. 

A. DEPARTMENT OF DEFENSE/NAVY (DOD/DON) MANPOWER 
PROGRAMMING 

Manpower requirements for the DOD/DON are determined, in 
part, by the authorized configuration of weapons systems, 
force structure, warfare tasking, and support thereof. A 
Naval activity's billet structure is, therefore, directly 
linked to the Department of Defense's (DOD) Planning, 
Programming, and Budgeting System (PPBS) . Initiated 
annually, the PPBS operates on an eighteen month cycle. 
Events in this cycle lead directly to the development and 
authorization of Navy manpower. 
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1. DOD Planning, Programming, and Budgeting System 
(PPBS) 

The President, National Security Council, Joint 
Chiefs of Staff (JCS) , and DOD evaluate the threat to 
national security based on intelligence collected. The JCS 
then develop a strategy to meet these threats to national 
security and promulgate it in the Joint Strategic Planning 
Document (JSPD) to the Secretary of Defense (SECDEF) . The 
SECDEF then issues guidance to the Military Departments in 
the areas of Fiscal Policy, Material Support Planning, and 
Preparation of the Program Objective Memorandum (POM) . The 
military departments submit POM to the SECDEF in response to 
this guidance. The POM submissions contain recommendations 
as to the forces and resources required to support national 
defense objectives as well as the rationale for these 
recommendations and risk assessments. Once force 
requirements have been determined, manpower requirements 
necessary to support the forces are established. 

[Ref . 1 : Chap. 3 ] . 

2 . DOD POM 

POM submissions are fiscally constrained and 
developed by fiscal year. Planned forces are programmed for 
eight fiscal years, and the manpower to support the forces 
is programmed for six fiscal years. "Upon receipt of the 
POM submissions from each Military Department, the SECDEF 
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requests the JCS to prepare the Joint Program Assessment 
Memorandum (JPAM)". [Ref. l:Chap. 3]. After analyzing the 
POM submissions and the JPAM, the SECDEF issues Program 
Decision Memorandum (PDMs) which include intended 
adjustments to the POM submissions. The Military 
Departments submit budget estimates based on Program 
Decision Memorandum to the SECDEF. After evaluating of 
these budget estimates, by SECDEF and Office of Management 
and Budget (OMB). SECDEF develops ”... Decision Package 
Sets and submits the DOD budget as part of the President's 
budget to Congress". 2 [Ref. l:Chap. 3]. Figure 2-1 
illustrates this PPBS process. Figure 2-2 illustrates the 
entire Manpower Requirements Determination Process. 

B. DON MANPOWER REQUIREMENTS DETERMINATION 
1. Operating Forces 

In the Department of the Navy (DON) , determining the 
manpower requirements for operating forces, i.e. ships, 
submarines, and aviation squadrons, is a complex process 
based on established engineering standards and other 
methodologies. Beginning with an operating unit's Required 
Operational Capability (ROC) or mission statement, and the 
Projected Operational Environment (POE) or specific 
operating scenario, then determining operating and 

2 Budget decisions are contained in Program Budget Decision 
(PBDs) and Defense Management Review Decisions (DMRDs) . 
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maintenance requirements for equipment installed at that 
unit to support the ROC/POE, the manpower analyst can apply 
a set of algorithms and engineering standards to determine 
the billet/manpower quality and quantity mix required for 
the unit to be fully mission capable. The wartime or full 
mission requirement billet structure for each unit in the 
operating force is then published in the unit's Manpower 
Document. 

Each Ship Manpower Document (SMD) and Squadron 
Manpower Document (SQMD) identifies the "minimum wartime 
qualitative and quantitative manpower requirements to 
support accomplishment of all assigned missions and Required 
Operational Capabilities in the Projected Operational 
Environment ROC/ POE". [Ref. l:Chap. 2J. These documents 

delineate, by departmental and divisional breakdown, the 
required officer and enlisted billet structure for an 
activity. This structure is defined in terms of officer 
warfare designations and grade; enlisted ratings, 
subspecialties or NECs, and paygrades; and the quantity 
required of each. 

2. Shore Activities 

The mission of Navy shore activities is to provide 
support to the operating forces. This support includes, but 
is not limited to, mission areas such as supply, fire 
fighting, intelligence, aircraft/ship rework, and staff 
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administrative activities. These support functions are not 
directly related to the operations of war-fighting hardware; 
therefore, the manpower effort required to provide these 
services cannot be measured by hardware engineering 
standards . 

The current method being used by DON to determine 
shore facility billet structure is the Efficiency Review 
(ER) process. Completion of ERs on all Naval shore 
activities is scheduled for FY 1994. From this process the 
Most Efficient Organization (MEO) which "defines the minimum 
quality and quantity of manpower required to produce the 
output (s) established in the activities Performance Work 
Statement (PWS)" will be derived. [Ref. l:Chap. 3]. "The 
Objective is to develop a manpower requirements baseline to 
use as a basis for programming all shore manpower 
requirements". [Ref. l:Chap. 2]. The end result of this 
entire process will be a Shore Manpower Document (SHMD) , 
similar in structure to the SMD and SQMD, for each U.S. Navy 
shore activity. 

3. Manpower Authorization (MPA) (OPNAV 1000/2) 

The next step in the manpower process is to 
determine peacetime mission requirements for all Naval 
activities, operating forces and shore activities. From 
these requirements, the peacetime force structure (ships, 
submarines, and aircraft, etc.) and shore facilities 
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structure are determined within budgetary constraints set by 
Congress. The Manpower Authorization (MPA) (OPNAV 1000/2) 
outlines Chief of Naval Operations (CNO) approved and funded 
billets for each Naval activity based on budgetary 
constraints, warfare priorities, and manning policies. 
Currently the DON'S goal is to have billet authorization 
(BA) levels at 91.5 percent of requirements for operating 
forces (deployable, military personnel only) and 90 percent 
or less of requirements for shore facilities (combined 
military, civilian, and civilian contract personnel) . 

[Refs. 2 and 3 ] . 

4. Personnel Levels 

The actual number of personnel assigned for duty to 
a Naval activity at any given time is determined by a 
complex set of factors, the explanation of which is beyond 
the scope of this thesis. It is sufficient to understand 
that the quality and quantity mix of personnel assigned to 
an activity ranges from 70 to 88 percent of BA, with each 
activity receiving its "fair share” of Navy personnel assets 
as determined by the Navy Manning Plan (NMP) for Enlisted 
personnel and the Officer Navy Manning Plan (ONMP) . 

[Refs. 2 and 3]. Because there is a difference between BA 
levels and actual personnel on board, it is vital that 
managers recognize this fact and manage these limited assets 
to ensure mission accomplishment and combat readiness. 
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C. PRESENT SYSTEM - ACTIVITY LEVEL MANPOWER ANALYSIS 
1. Personnel and Billet Data Sources 

The location of Naval personnel, based on official 
Permanent Change of Station (PCS) orders is maintained in 
database systems at the Consolidated Data Center (CDC) in 
Cleveland, Ohio. These systems are the Naval Enlisted 
System (NES) and the Officer Personnel Information System 
(OPINS) , commonly referred to as the Enlisted Master File 
and the Officer Master File. However, direct access to 
these databases is restricted to the upper echelons of the 
DON. 

Lower echelon activities such as ships, aviation 
squadrons and Naval bases do not have direct access to these 
database systems. Therefore, in order to fully analyze 
their manpower, data from several sources, internal and 
external to the command, are required. Internal documents 
include the personnel service records and personnel rosters. 
Externally generated documents used in activity level 
manpower analysis include the following: 

a. Manpower Authorization (MPA) (OPNAV 1000/2) 

The Manpower Authorization (MPA) , produced by the 
Navy Manpower Data Accounting System (NMDAS) , is used to 
fully identify the peacetime and mobilization billet 
structure of an activity. Two MPAs are published for each 
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command, one for officer billets and one for enlisted 
billets. Both are divided by department and division, and 
the billets assigned to each are delineated. 

Billets are identified by Billet Sequence Code 
(BSC) and Billet Title. Each billet is then assigned 
specific enlisted rating and Primary and Secondary Naval 
Enlisted Classification codes (PNEC/SNEC) requirements or 
officer warfare designator, grade, and subspecialty codes, 
if applicable. The authorized peacetime quantity for each 
billet is specified for the current Fiscal Year (FY) and 
subsequent five FYs. 

MPAs for an activity must be reviewed when the 
activity receives a new edition in order to identify or 
verify changes, if any, which have occurred to the 
authorized peacetime or wartime billet structure. Changes 
to an activity's billet structure are also identified 
through correspondence from the appropriate resource 
sponsor. For example, changes would include notification 
that an NEC is to be to be applied to specific ratings or 
notification granting authority to establish a new 
department within an activity and providing its associated 
billet structure. 

b. Enlisted Distribution Verification Report (EDVR) 

The Enlisted Distribution Verification Report 
(EDVR) , produced by NES, is received monthly by each Naval 
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activity with enlisted personnel assigned. This document 
lists assigned enlisted personnel alphabetically by last 
name and alphabetically by rate. Information provided on 
each person includes his actual rating and assigned rating 
(rating detailed against) , PNEC/SNEC held and distributed 
against, Projected Rotation Date (PRD) , End of Active 
Obligated Service Date (EAOS) , Active Duty Service Date 
(ADSD) , and Social Security Number (SSN) . Prospective 
personnel gains and losses are also identified by name and 
rate and estimated date of arrival or departure, 
respectively. The activity's billet authorization level and 
current month and nine month projected onboard manning 
levels are also provided as well as the NMP allotment for 
each rating. 

c. Officer Distribution Control Report (ODCR) 

The Officer Distribution Control Report (ODCR) , 
produced by OPINS, also published monthly, lists officers 
assigned to a command by BSC and Billet Title. Grade, 
designator, subspecialty, date of rank, PRD, sex, and SSN 
are also provided. 

Information on officer and enlisted personnel is 
also gleaned from Permanent Change of Station (PCS) orders 
and an individual's Personnel Record. 
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d. Detailing of Personnel 

Although officers are officially detailed to a 
specific billet within their activity, they may actually be 
assigned to a different billet by their Executive or 
Commanding Officer once they report for duty. Enlisted 
personnel are generally not detailed to a specific billet, 
but to an opening for a specific rating and paygrade or NEC 
requirement. There are exceptions to this system for 
enlisted personnel such as directed manning for Command 
Master Chief, Command Career Counselor billets and other 
high interest or controlled billets. When an enlisted 
member reports to an activity he/she is assigned to a 
department or division. The officer in charge of his/her 
work unit then assigns specific duties to be performed by 
the individual. 

2. Activity Management Levels 

There are three levels of management in an activity 
that are concerned with billet/personnel management: 
a. Executive Level 

This level consists of the Commanding Officer 
(CO) , Executive Officer (XO) , and selected Executive 
Assistants such as the Command Career Counselor (CCC) and 
Command Master Chief (CMC) . 
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b. Department Heads 

Department Heads are officers who are assigned 
responsibility for a major mission component of an activity 
such as Operations, Weapons, or Administration. Department 
Heads are assigned responsibility for managing several 
subordinate officers and numerous enlisted personnel who are 
grouped into functional subareas, called divisions, within a 
department . 

c. Division Officers 

Officers at this level of management are assigned 
responsibility for a division within a department. A 
division includes numerous enlisted personnel of varying 
rates . 

3. Management Views of Manpower 

The Executive Level, specifically the CO and XO, 
view enlisted manpower differently from the other two levels 
of management discussed above. The CO and XO generally view 
enlisted manpower in terms of the quantity of personnel 
onboard in each department or division; percentages of 
personnel onboard versus Billets Authorized (BA) ; a specific 
comparison of the number of billets and personnel assigned 
per department and division; and projected shortfalls and 
end strength. 

Officer manpower, on the other hand, is viewed from 
this level in terms of an individual assigned against a 
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specific billet, as well as overall current and projected 
officer manning levels. The Executive Officer of a command 
is responsible for the billet assignment of officers. The 
other members of the Executive Level, the CCC and CMC, deal 
primarily with career development, and morale and welfare of 
enlisted personnel, respectively. 

Department Heads and Division Officers view enlisted 
manpower in terms of BA versus personnel assigned ratios as 
well as specific enlisted billet assignments. Department 
Heads and Division Officers must actively project future 
manning levels against specific billets to ensure combat 
readiness and mission accomplishment. 

4. Manpower Analysis Process 

As mentioned previously, manpower analysis is the 
process by which an activity's personnel assets are matched 
to or balanced against its authorized billets. Often the 
manpower analysis and reports generation process at an 
activity is a manual process performed by an officer 
assigned as the Command Manpower Analyst or by an individual 
Department Head or Division Officer for their respective 
department, division, or work centers. These reports can 
take anywhere from a few minutes to several hours to produce 
manually, depending on the data required and the accuracy, 
currency, and availability of the data. 
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Because of the time lag between NES and OPINS 
database updates, publishing dates, and receipt of the EDVR 
and ODCR by an activity, there are frequently discrepancies 
between data in these documents data in and the individual's 
personnel record. The same is also true for NMDAS and the 
MPA. Information gleaned from the MPA, EDVR, ODCR, PCS 
orders, Personnel Records, billet assignments, and 
personnel/billet correspondence from higher authority is 
used to manage billets and manpower within an activity. 
Figure 2-3 illustrates the flows of data through the 
manpower analysis system. 

a . System Data Flows 

Figure 2-3 illustrates a general view of activity 
level manpower analysis. Sources and sinks as well as 
senders and receivers of data within the system are 
represented by boxes. The term 'Higher Authority' refers to 
an activity at an echelon higher than the activity 
performing manpower analysis. These Higher Authorities are 
responsible for making decisions on billet structure and 
assignment of personnel for subordinate activities. 

Higher Authority activities, in the context of 
this thesis, are as follows: 

Chief of Naval Operations (OP-12) , 
responsible office for MPA changes as 
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LEGEND 

(1) Billet Data (MPA & Notification Letter) 

(2) Personnel Data (ODCR.EDVR) 

(3) Personnel Data (Personnel Record) 

(4) Department Status Report 

(5) Division Status Report 

(6) Designator/Rating Status Report 

(7) Enlisted Billet Assignment 

(8) Grade/Paygrade Status Report 



(9) Department Manning Report 

(10) Division Manning Report 

(1 1 ) Officer Billet Assignment 

(12) Officer Manning Report 

(13) Officer Status Report 

(14) Personnel Gains/Losses Report 

(1 5) Officer and Enlisted PCS Orders 



Figure 2-3: Manpower Analysis Process Data Flow Diagram 



26 



directed by resource sponsors and manpower 
claimants . 

- Resource Sponsors, offices within OPNAV 
responsible for ensuring resources are 
available in the various warfare communities 
for mission accomplishment. 

EPMAC, performs placement for all active 
and Training and Administration of Reserves 
(TAR) enlisted duty personnel; detailing of 
non-designated airmen, seamen, and firemen; 
NEC management; production and distribution 
of EDVR using NES. 

- Naval Military Personnel Command (NMPC) , 
responsible for detailing and placement of 
officers, and detailing of all other enlisted 
personnel . 

Data flowing from Higher Authority will include 
billet information and personnel assignment information. 

Data flowing from the Commanding 
Officer/Executive Officer (CO/XO) source to the system will 
normally include only officer billet assignments. 

Information flowing to the CO/XO sink will be the various 
manpower analysis reports produced by the system and 
required by this level of management. These reports will be 
discussed in Section 5 of this chapter. 
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Division Officers and Department Heads will 
provide data to the system concerning enlisted billet 
assignments. As a data sink, this level of management will 
use reports generated by the system. 

Data from the Personnel Record will be used by 
the system to update the database, but no information or 
data will be sent from the system to the personnel record. 
b. Major System Components Data Flows 

Figure 2-4 illustrates the flow of data into and 
out of the two major components of a manpower analysis 
system. These major components are the processes for 
managing billet and personnel data and for creating reports. 

The data management process encompasses 
mechanisms for adding new data, modifying existing data, and 
deleting data which is no longer required. The primary 
purpose of any database is to maintain data for use by 
decision makers. The manpower analysis process ultimately 
produces reports for the users which present various 
consolidated views of an activity's manpower. Additionally, 
the database should be capable of providing simple lists of 
groups of data as well as responses to ad hoc queries. 

5. Reports 

Reports generated by the manpower analysis process 
are reflections of the management views of manpower. 

Reports on officer manpower would include a break-down of 
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Manpower 

Database 




LEGEND 

(1) Billet Data (MPA) and Notification Letter 

(2) Personnel Data (ODCR, EDVR) 

(3) Personnel Data (Personnel Record) 

(4) Officer Billet Assignment 

(5) Enlisted Billet Assignment 

(6) Officer Billet Data 

(7) Enlisted Billet Data 

(8) Officer Record 

(9) Enlisted Record 

(10) Officer and Enlisted PCS Orders 



(11) Department Billet Structure 

(12) Division Billet Structure 

(13) Grade/Pay grade Status Report 

(14) Designator/Rating Status Report 

(15) Department Status Report 

(16) Division Status Report 

(1 7) Officer Status Report 

(18) Officer Manning Report 

(19) Department Manning Report 

(20) Division Manning Report 

(21) Personnel Gains/losses Report 



Figure 2-4: Subprocesses Data Flow Diagram 
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personnel by paygrade and/or rank, billet summary by 
department/division, and a designator summary. Enlisted 
reports would include essentially the same break-down 
profiles. Both officer and enlisted reports provide 
strictly numeric views of the information in the database as 
well as views of specific billet/personnel assignments. 
Appendix D provides samples of reports illustrating views of 
the data normally required by activity level management. 
(These reports will be discussed in detail in Chapter III) . 
Not all levels of management need to see the same levels of 
detail in a report; therefore, the manpower data must be 
combined, analyzed, and presented in different formats. 

D. SUMMARY 

This chapter provided background information on the 
DOD/DON level manpower requirements determination processes. 
At the DON level, several documents are generated which, if 
used by an activity, provide all of the data necessary for 
effective manpower analysis. The manpower analysis process 
was summarized and an overview of reports generated by the 
process was presented. 

Chapter III reviews the methodology used to define data 
and functional requirements, develops the objects to be stored 
in the database, and determine the processes that create, 
modify and display these objects. 



30 



III. SYSTEM REQUIREMENTS 



This chapter defines the data and functional 
requirements for an automated manpower analysis system. 

Using data from several sources, a database is created which 
contains information on personnel assigned to an activity 
and the activity's billet structure. The database system 
will then process the information from the database to 
produce a series of predefined reports or to respond to ad 
hoc queries on the database. 

A. METHODOLOGY 

Object oriented methodology is used to define data and 
functional requirements for the database system. Using this 
methodology, the entities in the user's work environment are 
represented as objects to be stored in the database. An 
entity is any item in the user's work environment about 
which information is required to be stored. For example, an 
Officer would be an entity in a Naval activity's personnel 
management environment. The characteristics of each object 
are defined in terms of the data elements to be stored. 

Functional requirements for the database system are 
defined through the use of Data Flow Diagrams (DFDs) . DFDs 
present graphically how each object in the user's work 
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environment is created, modified, deleted, and displayed. 
DFDs also illustrate who is authorized to do what to each 
object and, within the user's work environment, to whom 
information from the system is given. 

1. DATA REQUIREMENTS DEFINITION 

Using object oriented methodology, the systems 
analyst must first identify those 'objects' in the user's 
environment that must be maintained and define their 
structure. An object is defined as a ”... named collection 
of properties that sufficiently describes an entity in the 
user's work environment.” A property is a ”... 
characteristic of an entity that is important to one or more 
users of the database application ...”, such as a person's 
name or rank. 3 "An entity is something the user perceives 
to be an independent unit...”, such as a department or an 
officer. [Ref. 4 : Chap 4], 

a. Object Definitions 

To define the objects in the user's environment 
for the AMA/PMS, both system outputs and entities in the 
user's work environment were examined to fully identify the 
characteristics or properties to be maintained by the 
system. These objects represent a consolidated view of the 
entities and their characteristics in the user's 



3 A property of an object may also be another object. In this 
case it is called an object property. 
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environment, a Naval activity. All Naval activities are 
divided into departments which are then divided into 
divisions. Some divisions are then further divided into 
workcenters (for the purpose of this thesis, an activity 
will be subdivided only to the division level) . Personnel 
are assigned to work within specific departments and 
divisions at an activity. The manpower of a Naval activity 
is viewed in terms of billet structure and personnel 
onboard. 



From the object oriented view of activity 
manpower, six entities are identified in the user's work 
environment of Manpower/Personnel Management about which 
data must be maintained. For the AMA/PMS these entities are 
defined as the objects: DEPARTMENT, DIVISION, OBILLET 

(officer billet) , EBILLET (enlisted billet) , OFFICER, and 
ENLISTED. Appendix A graphically presents the properties of 
each object. 

b. Object Specifications 

Once the objects have been defined, object 

specifications are developed. 

"Object specifications consist of two parts: object 

definitions and domain definitions. An object 
definition lists all the properties of an object and 
indicates the domain from which values for each property 
may be drawn. Domain definitions specify formats, 
lengths and special restrictions on the values of each 
domain". [Ref. 4: Chap 4). 
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Object Definitions and Domain Definitions are presented in 
Appendix B. 

c. Object Descriptions 

(1) Department and Division Objects. The 
billets 4 within an activity are divided into Departments and 
then subdivided into divisions. For example, the Aviation 
Maintenance Department would include divisions called 
Scheduling, Avionics and Electronics. The DEPARTMENT object 
is identified by Dname. This object contains the object 
properties of DIVISION, OBILLET, EBILLET, OFFICER, and 
ENLISTED, all of which may be multivalued. 

The DIVISION object is identified by 
DivName. This object also contains the object properties of 
OBILLET, EBILLET, OFFICER, and ENLISTED, as well as the non- 
object property Dname. Again, each of these object 
properties may be multivalued. 

(2) Billet Objects . Billets are categorized 
as requiring either an officer or an enlisted person to be 
assigned. The objects defined to represent these entities 
are OBILLET and EBILLET. Billet data is obtained from the 
Manpower Authorization (MPA) OPNAV 1000/2 or via official 
correspondence from a Resource Sponsor which identifies 
changes to an activity's billet structure, hereafter 

4 The billet structure of an activity defines the job 
organization. Therefore, a billet is a specific element of the 
work breakdown structure of the activity. 



34 



referred to as a Notification Letter. Billet data is 



entered into the system to create, modify, or delete a 
unique instance of OBILLET or EBILLET objects. These 
instances of OBILLET and EBILLET objects are then grouped to 
create instances of DEPARTMENT and DIVISION objects. 

The OBILLET and EBILLET objects contain 
several identical properties. Both objects are identified 
by a Billet Sequence Code (BSC) which is unique to each 
instance of that object. Each contains properties called 
Billet Title; Billet Authorization (BA) , the number of 
billets authorized for that BSC; Department Name (DName) ; 
and Division Name (DivName) . All billets are assigned to a 
department, but not all billets are assigned to a specific 
division. Several billets may be assigned to an area within 
the department commonly referred to as Departmental 
Administration . 

The OBILLET object contains properties for 
Grade and Designator (indicating the rank and warfare 
designator, respectively) , ideally required for that billet. 
Additionally, one or more instances of OFFICER object may be 
associated with a specific instance of the OBILLET object . 5 

Properties within the EBILLET object are 
Rating, an alphanumeric acronym for an enlisted technical 

5 More than one officer may be temporarily assigned to a single 
instance of OBILLET during periods of personnel turnover and 
reassignment. 
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rate and paygrade; paygrade; Primary or Secondary Naval 
Enlisted Classification (PNEC/SNEC) code, a numeric code 
specifying a technical subspecialty within a specific 
rating; BA; Dname; and DivName. One or more instances of 
ENLISTED object may be associated with a single instance of 
EBILLET object. 6 

(3) Personnel Objects. Members of the Armed 
Forces are either Commissioned Officers or Enlisted 
Personnel. Personnel data gleaned from the Officer 
Distribution Control Report (ODCR) , the Enlisted 
Distribution Verification Report (EDVR) , Permanent Change of 
Station (PCS) orders, Personnel Service Records, and 
personnel data input or change forms (as created and used by 
each activity) is entered into the system to create, modify, 
and delete unique instances of OFFICER and ENLISTED objects. 

Each instance of the OFFICER object is 
identified by the individual's SSN. This object contains 
the properties of Name, Grade, Projected Rotation Date 
(PRD) , and Date of Rank, as well as the object properties of 
DEPARTMENT and DIVISION. The property Collateral Duties may 
be multivalued and describes the non-billet duties assigned 
to an officer such as Urinanalysis Officer or Navy Relief 
Coordinator. The object properties, OFFICER, DEPARTMENT, 



‘More than one Enlisted person may be temporarily assigned to 
an instance of EBILLIT during periods of turnover and reassignment. 
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and DIVISION are single valued, however, the object property 
of OBILLET may be multivalued as an officer may be assigned 
to more than one billet. 

The ENLISTED object is identified by SSN 
for each instance in the database. Other properties in this 
object include Name, Rating, Paygrade, Rate, PNEC, SNEC, 

PRD, End of Active Obligated Service (EAOS) date, Date of 
Rank, and Time in Service. As Enlisted personnel are 
initially assigned to a department and division then to a 
billet, these object properties are included. An enlisted 
member may only be assigned to a single department or 
division at a time but may be assigned to more than one 
billet. The property Collateral Duties is multivalued. 

These non-billet duties may include assignments such as 
Watch Section Leader or Training Petty Officer, 
d. Management Views of Objects 

The Executive level of a command views the 
activity as a collection of DEPARTMENT objects, each of 
which is divided into a collection of DIVISION objects. 

Each of these objects is viewed as containing several 
instances of OBILLET and EBILLET objects. From this level, 
OBILLETs are viewed as containing instances of OFFICER 
object. Enlisted personnel are viewed as belonging to a 
specific instance of DEPARTMENT or DIVISION object. 
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Lower management levels of a command, i.e., 
Department Heads and Division Officers, view the activity in 
terms of a specific instance of a DEPARTMENT or DIVISION 
object and the OBILLET and EBILLET objects contained 
therein. OBILLET and EBILLET objects are then viewed as 
containing one or more instances of OFFICER and ENLISTED 
objects, respectively. 

Personnel are viewed as instances of OFFICER or 
ENLISTED objects. At the Executive level, officer personnel 
are viewed as assigned to one or more specific instances of 
OBILLET object, and enlisted personnel to a specific 
instance of DEPARTMENT object or DIVISION object. At the 
Department and Division levels, enlisted personnel are 
viewed as assigned to one or more specific instances of 
EBILLET object. An officer or enlisted individual may be 
temporarily unassigned to a billet or assigned to a billet 
with another individual (see previous footnotes) . 

B. FUNCTIONAL REQUIREMENTS 

The AMA/PMS consists of a single application with two 
main processes, the Manage Manpower process and the Create 
Reports process. (Appendix C, Figures C-l and C-2) . 

1. Manage Manpower Process 

This process is divided into two lower level 
processes, Manage Billet Objects and Manage Personnel 
Objects. (Appendix C, Figures C-3 and C-4) . 
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a. Manage Billet Objects 

This lower level process contains the mechanisms 
for creating, modifying, and deleting instances of OBILLET 
and EBILLET objects. Using source documents such as the MPA 
(OPNAV 1000/2) or notification letters from Resource 
Sponsors, the user will be able to maintain all billet data 
used by the AMA/PMS. Instances of OBILLET and EBILLET 
objects will be created, modified and deleted in this 
process. Instances of DEPARTMENT and DIVISION objects will 
be created via the Create OBILLET and Create EBILLET 
processes. DEPARTMENT and DIVISION objects can be modified 
and deleted independent of the Update OBILLET and Update 
EBILLET processes. (Appendix C, Figures C-6 through C-10) . 

b. Manage Personnel Objects 

Using data gleaned from PCS orders, ODCR, EDVR, 
personnel service records, etc., this process provides the 
mechanisms for managing the personnel data used by the 
AMA/PMS. Instances of the OFFICER and ENLISTED objects will 
be created, modified, and deleted in this process. 

(Appendix C, Figures C-ll through C-14) . 

2 . Create Reports Process 

The second major component of the AMA/PMS is the 
Create Reports Process. (Appendix C, Figure C-15) . By 
using data stored in the database by the Manage Manpower 



39 



Process, the system generates reports. These reports 
provide various views of the data for use in analyzing an 
activity's manpower. 

Nine standard report outputs are produced by the 
AMA/PMS. (Appendix C, Figures C-15 thourgh C-21 and 
Appendix D, Figures D-5 through D-ll) . There are two 
general types of reports generated by the Generate Reports 
process: Manning Reports and Status Reports. 

a . Manning Reports 

Manning Reports provide information linking an 
officer or enlisted member directly to one or more 
authorized billets. The Department/Division Manning Report 
will be created by drawing required data from instances of 
ENLISTED object, and DEPARTMENT object. Officer Manning 
Report will contain information gleaned from instances of 
OFFICER object and DEPARTMENT object. The Personnel 
Gains/Losses Report will draw on the OFFICER and ENLISTED 
objects to produce a report showing those personnel known to 
be ordered to the activity but not yet received, and those 
personnel whose PRDs are within six months of the date of 
the report. (Appendix D, Figures D-5 through D-7) . 

b. Status Reports 

Status Reports provide a numeric overview of an 
activity in terms of billets authorized and personnel 
assigned. The system will focus on various properties within 
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an object depending on the status report being produced. It 
will then calculate the number of times that property occurs 
in the instances of an object. 

Five status reports are generated by the system. 
The Officer Status Report provides information on authorized 
officer billet levels and the number of officer personnel 
assigned to the activity. The Department/Division Status 
Report provides the same comparison for enlisted personnel. 
The Paygrade Status Report is a comparison between the 
number of billets authorized for each enlisted and officer 
paygrade and the number of personnel assigned within each 
paygrade. The Designator/Rating Status Report provides a 
comparison between the number of billets authorized for each 
officer designator and each enlisted rate and the number of 
personnel assigned, broken down by paygrade. (Appendix D, 
Figures D-8 through D-ll) . 

C . SUMMARY 

This chapter provided a brief overview of Object 
Oriented Database Analysis methodology. Data requirements 
for the AMA/PMS are presented as Objects in Appendix A, and 
defined in Object Specifications presented in Appendix B. 
Function requirements for the system, the data used in these 
processes and, the objects created and used were examined in 
detail. Data Flow Diagrams (DFD) for the AMA/PMS are 
presented in Appendix C. 
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Chapter IV will present the logical database design 
using Object Oriented methodology and the Relational 
Database Model. 
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IV. DATABASE DESIGN 



In Chapter III the functional and data requirements for 
the AMA/PMS were specified. Using an object oriented 
database methodology, the entities in the user's environment 
are represented as objects to be stored in the database. 

The functional requirements of the system are represented by 
data flow diagrams showing how objects are created, 
modified, deleted, and displayed and who is authorized to do 
what on these objects. 

In this chapter, the logical database and application 
design are presented. In the logical design phase, database 
objects, as defined in the user's requirements phase, are 
transformed into a relational diagram. In the application 
design phase, menu structures, detailed forms and reports, 
and pseudo code for application programs are developed for 
the data flow diagrams developed in the user's requirement 
phase . 

A. LOGICAL DATABASE DESIGN 

1. Relational Database Model 

The Relational Database Model is the approach used 
to organize the data in the logical design. "The relational 
database model is based on the concept that data is stored 
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(at least conceptually) in two-dimensional tables called 
relations. Each row in the table represents a record”, 
i.e., an instance of an entity. "Each column represents a 
field” or characteristic of an entity. ”. . .A column is 

called an attribute”. [Ref. 4: Chap 5). Each table is 
generally referred to as a file. 

There are restrictions placed on relations, however. 
"First, attributes are single valued; neither repeating 
groups nor arrays are allowed. Second, entries in any 
column are all of the same kind”. [Ref. 4:Chap 5]. For 
example, for each record (row) in a file (table) there would 
be only a single entry in the column (attribute) called 
'age'. No two records in a file may be identical. 

2. Object Relationships 

First, in order to convert objects into relations, 
the analyst examines the relationships among the objects and 
constructs a preliminary relational diagram. It should be 
noted that there is not necessarily a one to one correlation 
when converting objects into relations. Next, all relations 
are normalized to eliminate modification anomalies. 
Additional relations will need to be created to to 
accomplish normalization. 

The relationships between relations are determined 
from the types of objects from which they are derived. 

These relationships are classified as one to one, one to 
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many, and many to many, and apply only to the relationship 
between any two relations. Relationships between relations 
further are designated as either mandatory or optional. 

In a one to one relationship, the key of either 
relation is placed into the other as a foreign key. In a 
one to many (parent to child) relationship, the key of the 
parent is placed into the child relation as a foreign key. 

An intersection relation is created to represent a many to 
many relationship. The key of an intersection relation is 
the composite key of both of the parent relations. 

3. Relational Diagram 

From the Object Diagram and Object Specifications 
defined in Chapter III and Appendices A and B, relations and 
relation definitions are produced. Appendix E is the 
Relational Diagram for the AMA/PMS. It graphically 
represents the relationships between relations as derived 
from the Object Diagrams in Appendix A. Appendix F contains 
the Relation Definitions and the physical description of the 
Domain Definitions only. 

All of the objects defined for the AMA/PMS, Appendix 
A, are compound objects. Each contains at least one object 
property which is either single or multi-valued. The 
OFFICER and ENLISTED objects are, additionally, composite 
objects as they contain a multi-valued, non-object property. 
The intersection relation DIVASSIGN is created to represent 



45 



the many to many relationship between DIVISION and OFFICER. 
The intersection relations OASSIGN and EASSIGN were defined 
in order to represent the many to many relationship between 
the compound objects; OFFICER and OBILLET, and ENLISTED and 
EBILLET, respectively; which contain each other as object 
properties. The relation COLDUTIES was created to 
illustrate the composite object relationships between 
OFFICER and ENLISTED and their multi-valued, non-object 
property COLDUTY. (Appendix E) . 

In the Relational Diagram, Appendix E, the key for 
each relation is indicated by an underlined attribute. A 
foreign key is identified by an asterisk. The key for an 
intersection relation is the key for each of the parent 
relations, indicated by an underline and an asterisk. A 
mandatory relationship is represented by a bar on the 
connecting line and an optional relationship by a circle. 

4 . Normalized Relations 

All relations in the AMA/PMS are in Boyce-Codd 
Normal Form. The relations have been developed to avoid 
modification anomalies which are undesirable consequences 
resulting from changing the data in relations. There are 
three types of modification anomalies: deletion, insertion, 

and update. 

A deletion anomaly is caused when deletion of the 
facts about one entity inadvertently causes the deletion of 
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facts about another entity. For example, if, in the 
AMA/PMS, an officer record is deleted and a billet record is 
also mistakenly deleted this is a deletion anomaly. 

An insertion anomaly would exist if, for example, a 
billet record could not be entered into the database until 
an officer or enlisted person was assigned to the billet. 
This should result in an incomplete database for billet 
structure. 

An update anomaly occurs when redundancy of data is 
required based on the database structure. For example, if 
an individual is assigned to more than one billet and a 
separate record on the individual is created in the file for 
each billet held. If data needed to be changed on the 
individual, such as rank, then for each billet record on the 
individual, a change would have to be made. This requires 
too much record updating for a simple data change. 

To solve these anomalies, using the above examples, 
three relations would be created; one containing personal 
information on an individual and one containing billet 
information, and an intersection relation linking an 
individual to a specific billet(s). 
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B. RELATIONSHIP DESCRIPTIONS 



1 . DEPARTMENT 

The DEPARTMENT object is a compound object as it 
contains the object properties of DIVISION, OFFICER, 
ENLISTED, OBILLET, and EBILLET. All are multi-valued. 
Because DEPARTMENT is a compound object, the key to this 
relation, DName, is placed as a foreign key in each of its 
child relations. All of the relationships between 
DEPARTMENT and its child relations are one to many. A 
DEPARTMENT may have multiple values of DIVISION, OFFICER, 
ENLISTED, OBILLET, and EBILLET. Each of these child 
relations is, however, associated with only one DEPARTMENT. 

a. DEPARTMENT and DIVISION 

The relationship between DEPARTMENT and DIVISION 
is mandatory /optional . A DIVISION must belong to a 
DEPARTMENT, but a DEPARTMENT may not have any DIVISIONS 
assigned, such as the Safety Department in an aviation 
squadron. 

b. DEPARTMENT and OFFICER 

The relationship between DEPARTMENT and OFFICER 
is mandatory/optional. An OFFICER must be assigned to a 
DEPARTMENT, but a DEPARTMENT might not necessarily have an 
OFFICER assigned at all times or may have several OFFICERS 
assigned . 
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c. DEPARTMENT and ENLISTED 



The relationship between DEPARTMENT and ENLISTED 
is the same as that for OFFICER, one to many and 
mandatory/optional . 

d. DEPARTMENT and OBILLET 

The relationship between DEPARTMENT and OBILLET 
is mandatory/mandatory as all DEPARTMENTS must have at least 
one OBILLET assigned and an OBILLET is always associated 
with a DEPARTMENT. 

e. DEPARTMENT and EBILLET 

Between DEPARTMENT and EBILLET, however, the 
relationship is mandatory/optional. An EBILLET must be 
associated with a DEPARTMENT, but a DEPARTMENT need not have 
any or may have several EBILLETS assigned. 

2. DIVISION 

DIVISION is a compound object containing the object 
properties OFFICER, ENLISTED, OBILLET and EBILLET. Each of 
these object properties is multi-valued. The key to the 
DIVISION relation, DivName, is placed as a foreign key in 
each of its child relations. 

a. DIVISION and OFFICER 

The relationship between DIVISION and OFFICER can 
be many to many . 7 This relationship is illustrated through 

7 This is not often done and usually is a result of manning 
shortfalls. 
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the creation of an intersection relation called DIVASSIGN. 



Its key is the composite key, DivName and SSN (SSN is the 
key to OFFICER) . More than one OFFICER may be assigned to a 
DIVISION, optional relationship, and an OFFICER may be 
assigned as a Division Officer to more than one DIVISION 
(also an optional relationship) 8 . 

b . DIVISION and OBILLET 

The relationship between DIVISION and OBILLET is 
optional/optional. A DIVISION (or workcenter) need not have 
OBILLETs associated with it, for example the Career 
Counseling Division, and an OBILLET may be assigned only to 
a DEPARTMENT and not a DIVISION. 

C. DIVISION and ENLISTED /EBILLET 

DIVISION is related to both ENLISTED and EBILLET 
in a one to many, mandatory/optional relationship. An 
ENLISTED must be assigned to a DIVISION, although it is 
possible that a DIVISION has no ENLISTED associated. Many 
ENLISTED may be assigned to a DIVISION, but an ENLISTED 
person is generally assigned to only one DIVISION . 9 

EBILLET must be associated with DIVISION, however 
DIVISION need not contain EBILLETs. 



8 A Department Head is not necessarily a Division Officer. 

9 As stated previously, billets may be assigned to a Department 
for administrative support. 
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3. OFFICER and OBILLET 



OFFICER is a composite and compound object. OFFICER 
contains Collateral Duties as a multi-valued, non-object 
property. This relationship is illustrated by the COLDUTY 
relation. The composite key of this relation is SSN from 
OFFICER and Colduty. Certain collateral duties must be 
assigned to OFFICER, but not all OFFICERS are required to 
hold collateral duties. Thus the mandatory/optional 
relationship. 

OFFICER contains OBILLET as a multi-valued object 
property, and OBILLET contains OFFICER in the same manner. 
This creates compound objects with a many to many 
relationship. In order to avoid update anomalies, an 
intersection relation called OASSIGN is created. Its key is 
the composite key, SSN and BSC (BSC is the key for OBILLET) . 
An OFFICER may be assigned to more than one OBILLET or none 
at all. OBILLET may be allotted to more than one OFFICER or 
to none at all . 10 

4. ENLISTED and EBILLET 

ENLISTED is a composite and compound object. 

ENLISTED contains Collateral Duties as a multi-valued, non- 
object property. This relationship is illustrated by the 
COLDUTY relation. The composite key of this relation is SSN 



l0 For a period of time two officers may be assigned to the same 
billet if one is relieving (replacing) the other. A billet may be 
gapped (unfilled) during manning shortfalls. 
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from ENLISTED and Colduty. Certain collateral duties must 
be assigned to ENLISTED but not all ENLISTEDs are required 
to hold collateral duties. Thus the mandatory/optional 
relationship. 

ENLISTED contains EBILLET as a multi-valued object 
property, and EBILLET contains ENLISTED in the same manner. 
This creates compound objects with a many to many 
relationship. In order to avoid update anomalies, an 
intersection relation called EASSIGN is created. Its key is 
the composite key, SSN and BSC (BSC being the key for 
EBILLET) . An ENLISTED may be assigned to more than one 
EBILLET or not at all. EBILLET may be allotted to more than 
one ENLISTED or none at all." 

C. APPLICATION DESIGN 

The application design phase is the final step in 
logical database design. First, the number of applications 
and application scope are determined. For the AMA/PMS, 
there are two applications. Manpower Management and Reports. 
The Manpower Management application uses all object views 
specified in Appendix A for data entry, modification, 
display, and deletion. The Reports application manipulates 
the data within the database to produce either predefined 



"For a period of time two enlisted personnel may be assigned 
to the same billet if one is relieving (replacing) the other. A 
billet may be gapped (unfilled) during manning shortfalls. 
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reports or respond to user ad hoc queries. The application 
design process entails materialization of objects into data 
input and display/modify screens and output design. Data 
outputs are in the form of predefined reports, Appendix D. 
The scope of the application is specified in Appendix G, 
Update, Display and Control Mechanisms. 

1. Menu Hierarchy 

Access to the two AMA/PMS applications will be menu- 
driven for ease of use. The menu hierarchy, Appendix H, 
consists of three layers below the Main Menu. The Main Menu 
provides initial access to either application, Manpower or 
Reports. Design materializations, input and display/modify 
screens, and menu logic are presented in Appendices D and I, 
respectively. 

a. Manpower Menu 

The Manpower Menu, provides access to the next lower 
menu layer through either of two paths; Billet Data or 
Personnel Data. 

(1) Billet Data Menu . The Billet Data Menu 
offers the user the choice to Add New Billet data, Edit 
Billet Data, or Delete an existing billet record. Any of 
these three choices leads to the next lower menu layer. If 
the user desires to Add New Billet data the system, through 
the Billet Type Menu, will allow the choice of either an 
Officer or Enlisted Billet data input screen. Selection of 
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the Edit Billet Data or the Delete Billet option leads to a 
menu which will allow a choice of three Billet Display 
formats; by Department, Division, or Billet Sequence Code 
(BSC) . 

The Billet Data Menu also provides direct 
access to the Personnel Data Menu and to the Reports 
application menu, without requiring the user to return to 
the previous menu layer; and allows the user to return to 
the Manpower Menu. The Billet Type and Billet Display menus 
allow the user to return only to the Billet Data Menu. 

(2) Personnel Data Menu . The Personnel Data 
Menu presents the user with the choice to Add New Personnel 
data. Edit Personnel Data, or Delete Personnel data. If the 
user chooses to Add New Personnel an additional menu will 
provide the user the choice of the Officer or Enlisted 
Record Type input screen. The Record Type menu allows the 
user to return only to the Personnel Data menu. 

The Personnel Data Menu also provides 
direct access to the Billet Data Menu and to the Reports 
application menu, without requiring the user to return to 
the previous menu layers; and allows the user to return to 
the Manpower Menu. 

b. Reports Menu 

The Reports Menu, provides direct selection of 
the Gains/Losses Report and/or access to the next lower menu 
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layer through either of two paths; Manpower Reports or 
Status Reports. Additionally, the user may request Ad Hoc 
queries against the data base. All reports will be 
displayed on screen and provide the user the option to print 
the specified report. 

(1) Manpower Reports Menu. This menu provides 
the user the option of displaying activity enlisted manpower 
information either by Department or Division. A report of 
the activity officer manpower is also an option. 

The Manpower Reports menu provides direct 
access to the Status Reports Menu or to the Manpower Menu as 
well as the previous menu. 

(2) Status Reports Menu. This menu presents 
the user with four options for activity enlisted personnel 
status reports; by Department, Division, Paygrade, or 
Designator/Rate . Officer Status Reports is an additional 
menu option. 

The user is provided direct access to the 
Manpower Reports and Manpower Menus as well as the option to 
return to the Reports Menu. 

D. CONTROL MECHANISMS 

The AMA/PMS database will contain information protected 
under the Privacy Act as well as Combat Readiness related 
information. It therefore must be protected by a computer 
security system that as a minimum consists of password 
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access controls. Additional controls on the system consist 
of data integrity requirements. Data integrity will be 
validated against tables which have specified allowable 
values for data elements such as Rate/Rank, Designator, 
PNEC/SNEC, and BSC. The presence of data in Name, SSN, PRD, 
EAOS, etc. fields will be the control mechanism for these 
data elements. The field for Collateral Duties will be a 
free-form comments field. Update, Display and Control 
Mechanisms are specified in detail in Appendix G. 

1. Data Input 

a. Billets 

All fields on the Officer Billet Input screen are 
mandatory. With the exception of the PNEC and SNEC fields 
on the Enlisted Billet input screen, all fields are 
mandatory. 

b . Personnel 

Mandatory fileds on officers are first and last 
names, Grade Designator, SSN, and PRD. For enlisted 
personnel the mandatory fields are first and last name, SSN, 
Rating, paygrade. Rate, and PRD. All other fields for both 
inputs are optional. 

Billet assignments are either made through the 
input mode for personnel records or by modifying an existing 
record . 
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2. Data Display, Modification, or Deletion 

a. Billet 

Billet data may be displayed on the screen by 
specifying Department or Division. The user then scrolls 
through the data as needed. Billet data may also be 
displayed by specifying BSC. Once displayed, billet data 
may be modified on screen or deleted from the database. 

b . Personnel 

Personnel data may be displayed on the screen by 
specifying the personnel record desired by SSN or by Name 
and Grade/Rating combination. Once displayed, personnel 
records may be modified or deleted from the database. 

c. Reports 

All pre-defined report formats will be displayed 
on screen. Information in the reports cannot be modified or 
deleted from the reports process. 

E. SUMMARY 

This chapter presented the logical database design for 
the AMA/PMS using Object Oriented Database Design 
methodology and the Relational Database Model. All objects 
specified in Appendix A, were transformed into normalized 
relations. These relations contain no modification 
anomalies. The relationships between these relations are 
illustrated in Appendix E and described in Section B of this 
chapter. Database control mechanisms are described in 
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Appendix G. Input/Display screens. Menu Hierarchy and menu 
samples, and menu logic (pseudo code) are presented in 
Appendices D, H, and I, respectively. 
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V. 



SUMMARY AND CONCLUSIONS 



A. SUMMARY 

With ever increasing DOD budget cuts, the need to 
actively manage limited manpower assets is vital to 
successful accomplishment of the Navy's mission. The 
information needed for manpower analysis at the activity 
level is readily available in documents published by higher 
authority: MPA, ODCR, and EDVR. However, this information 
is rarely used to manage manpower because of a lack of 
knowledge on the part of COs, XOs, Department Heads, and 
Division Officers on the mechanisms and importance of the 
process . 

Failure to manage manpower at the activity level can 
have serious negative impact on mission/combat readiness. 
Conversely, proactive manpower analysis can avert serious 
manning shortfalls. 

Object oriented methodology was used to fully define 
functional and data requirements. Data requirements are 
presented in Appendix A, Object Diagrams; and Appendix B, 
Object Definitions. Dataflow diagrams for the AMA/PMS are 
presented in Appendix C. System output/report formats are 
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presented in Appendix D. Functional requirements are 
described in Appendix G, Update, Display, and Control 
Mechanisms . 

The Relational Database Model was used as a design tool. 
Objects were transformed into relations in Boyce-Codd Normal 
Form, thereby eliminating all possible modification 
anomalies. The design specifications are presented in 
Chapter IV. The Relational Diagram and Relation Definitions 
are presented in Appendices E and F, respectively. The 
AMA/PMS is designed to be menu driven. The Menu Hierarchy 
and Menu Logic (pseudo code) are contained in Appendices H 
and I . 

B. ALTERNATIVE FUNCTIONALITY 

The AMA/PMS is designed strictly to manage activity 
level active duty military manpower. The design can easily 
be modified, after requirements have been specified, to 
accommodate civilian and/or reserve manpower. 

Additional functionality could be gained by designing 
system interfaces to allow mainframe to personal computer 
down-load of billet information from NMDAS, enlisted 
personnel data from NES, and officer personnel data from 
OPINS. Some modification of domain definitions would be 
required to ensure data compatability . This would 
significantly reduce data input time to the database. 



60 



APPENDIX A: OBJECT DIAGRAMS 
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Figure A-l: Object Diagrams 



61 



62 



APPENDIX B: OBJECT DEFINITIONS 



A. OBJECT DEFINITIONS 

1. Department Object 

DName; Department name 

DIVISION; DIVISION object; MV; SUBSET {DivName, 
OBILLET, EBILLET} 

OFFICER; OFFICER object; MV; SUBSET {Name, Grade, 
Designator, PRD} 

ENLISTED; ENLISTED object; MV; SUBSET {Name, Rating, 
Rate, Rank, PNEC, SNEC, PRD, EAOS} 

OBILLET; OBILLET object; MV; SUBSET {BSC, Billet 
Title, Grade, BA} 

EBILLET; EBILLET object; MV; SUBSET {BSC, Billet 
Title, Rating, BA} 

2. Division Object 

DivName; Division name 

DEPARTMENT; DEPARTMENT object; SUBSET {DName} 

OFFICER; OFFICER object; MV; SUBSET {Name, Grade, 
Designator, PRD} 

ENLISTED; ENLISTED object; MV; SUBSET {Name, Rating, 
Rate, Rank, PNEC, SNEC, EAOS} 

OBILLET; OBILLET object; MV; SUBSET {BSC, Billet 
Title, Grade, BA} 
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EBILLET ; EBILLET object; MV; SUBSET {BSC, Billet 
Title, Rating, BA} 

3. Obillet Object 

BSC; Billet Sequence Code 
Billet Title; Name of billet 
Grade; Officer rank required for billet 
Designator; Warfare speciality required for billet 
BA; Billet Authorization, number of billets 
authorized; MV 

DEPARTMENT; DEPARTMENT object; SUBSET {DName} 
DIVISION; DIVISION object; SUBSET {DivName} 
OFFICER; OFFICER object; MV; SUBSET {Name, Grade, 
Designator, PRD} 

4. Ebillet Object 

BSC; Billet Sequence Code 
Billet Title; Name of billet 

Rating; Technical speciality required for billet 
Paygrade; Paygrade required for billet 

Rate; Alpha-numeric combination of Rating 
and Paygrade required for billet 
PNEC; Primary Naval Enlisted Classification Code 
SNEC; Secondary Naval Enlisted Classification Code 
BA; Billet Authorization, number of billets 
authorized; MV 

DEPARTMENT; DEPARTMENT object; SUBSET {DName} 
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DIVISION; DIVISION object; SUBSET {DivName} 

ENLISTED; ENLISTED object; MV; SUBSET {Name, Rating, 
Rank, Rate, PNEC, SNEC, PRD} 

5. Officer Object 

SSN; Officer's Social Security Number 
Name; Officer's full name 
Grade; Officer's Rank 
Designator; Warfare designator 
PRD; Projected Rotation Date 
Date of Rank; date promoted to current rank 
Colduties; Comments or collateral duties; MV 
DEPARTMENT; DEPARTMENT object; SUBSET {DName} 
DIVISION; DIVISION object; SUBSET {DivName}; MV 
OBILLET; OBILLET object; MV; SUBSET {bsc, billet 
title} 

6. Enlisted Object 

SSN; Enlisted's Social Security Number 
Name; Enlisted's full name 
Rating; Individual's technical speciality 
Paygrade; Individual's paygrade 

Rate; Alpha-numeric combination of individual's 
Rating and Paygrade 

PNEC; Primary Naval Enlisted Classification Code 
SNEC; Secondary Naval Enlisted Classification Code 
PRD; Projected Rotation Date 
EAOS; Date - End Active Obligated Service 
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Date of Rate; date promoted to current rate 
Time in Service; Number of years, months, days 
enlisted in Navy 

Colduties; Comments or collateral duties; MV 
DEPARTMENT; DEPARTMENT object; SUBSET {DName} 
DIVISION; DIVISION object; SUBSET {DivName} 
EBILLET; EBILLET object; MV; SUBSET {bsc, billet 
title} 

B. DOMAIN DEFINITIONS 

1 . ba : 

Numeric 4 

Number of Billets Authorized 

2. billet title: 

Text 20 

Title of authorized billet as it appears on the 
OPNAV 1000/2 

3. bsc: 

Numeric 5 

Billet Sequence Code as it appears on the OPNAV 
1000/2 

4. cob: 

Numeric 4 

Number of personnel Currently on Board 

5. date: 

Numeric, mask yymmdd, 
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where yy is any 2 digits, mm is any 2 digits from 
01 to 12, dd is any 2 digits from 01 to 31. 

6. date of rank: 

Same as number 5 above 

7. date of rate: 

Same as number 5 above 

8. designator: 

Numeric 4 

Four digit code representing an Officers warfare 
specialty 

9. divname: 

Text 15 

Name of a division as it appears on the OPNAV 1000/2 

10. dname: 

Text 15 

Name of a department as it appears on the OPNAV 
1000/2 

11. grade: 

Text 4, mask XXXX 

where XXXX is one of: FADM, ADM, VADM, RAMU, 

RAML, CAPT, CDR, LCDR, LT, LTJG, ENS , CW04 , CW03 , 
CW02 

Grade title of a Comissioned Officer 

12. name: 

text 40: Mask: 
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first name; Text 15 
mi; Text 2 
last name; Text 23 
Full name of all personnel assigned 

13. nec: 

Numeric 4 

Naval Enlisted Classification Code as found in the 
NEC Manual or on the OPNAV 1000/2 (used for Primary 
and Secondary NEC (PNEC/SNEC) ) 

14. paygrade: 

Text 5, mask XXXXX, 

where XXXXX is one of:E9, E8, E7, E6, E5, E4, 
E1-E3 

Paygrade of Enlisted Personnel 

15. pnec: 

Numeric 4 

See NEC above. 

16. pob: 

Numeric 4 

Projected on Board number of personnel 

17. prd: 

Text 5, mask AYYMM 

where A indicates that an individual is has not 
yet arrived on board (otherwise this digit is 
blank), YY is any 2 digits from 00 to 99, and MM 
is any two digits from 01 to 12 
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Projected Rotation Date of personnel assigned 

18. rate: 

Text 5, mask XXXZZ 

where XXX is enlisted rate and ZZ is one of: 1, 
2, 3, C, CS, CM 

Enlisted rating, combination of enlisted technical 
specialty and rate 

19. rating: 

Text 3 , mask XXX 

where XXX is an enlisted speciality rating as 
found in the NEC Manual. 

20. snec: 

Numeric 4 

See NEC above. 

21. ssn: 

Numeric 9 

Personnal identification number assigned by the 
Social Security Administration 
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APPENDIX C: DATAFLOW DIAGRAMS 




LEGEND 



(1) Billet Data (MPA & Notification Letter) (9) 

(2) Personnel Data (ODCR.EDVR) (10) 

(3) Personnel Data (Personnel Record) (11) 

(4) Department Status Report (12) 

(5) Division Status Report (13) 

(6) Designator/Rating Status Report (14) 

(7) Enlisted Billet Assignment (15) 

(8) Grade/Paygrade Status Report 

Figure c-1: AMA/PMS 



Department Manning Report 
Division Manning Report 
Officer Billet Assignment 
Officer Manning Report 
Officer Status Report 
Personnel Gains/Losses Report 
Officer and Enlisted PCS Orders 
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Manpower 

Database 




LEGEND 

(1) Billet Data (MPA) and Notification Letter 

(2) Personnel Data (ODCR, EDVR) 

(3) Personnel Data (Personnel Record) 

(4) Officer Billet Assignment 

(5) Enlisted Billet Assignment 

(6) OBILLET Object 

(7) EBILLET Object 

(8) OFFICER Object 

(9) ENLISTED Object 

(10) Officer and Enlisted PCS Orders 



(11) DEPARTMENT Object 

(12) DIVISION Object 

(13) Grade/Paygrade Status Report 

(14) Designator/Rating Status Report 

(15) Department Status Report 

(16) Division Status Report 

(17) Officer Status Report 

(18) Officer Manning Report 

(19) Department Manning Report 

(20) Division Manning Report 

(21) Personnel Gajrts/Losses Report 



Figure C-2 : Manage Manpower and Create Reports Processes 

Diagram 
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l e gend 

EDVR * Enlisted Distribution Verification Report 
ODCR = Officer Distribution Control Report 
PCS » Permanent Change of Station 
AN, SN, FN = Airman, Seaman, Fireman 



Figure C-3: 



Manage Manpower (Update Objects) 
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Database 




LEGEND 

ODCR = Officer Distribution control Report 
EDVR = Enlisted Distribution Verification Report 
PCS » Permanent Change of Station 
AN, SN, FN = Airman, Seaman, Fireman 



Figure C-4: Manage Objects 
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(A) 






Figure C-5: Update DEPARTMENT and DIVISION Objects 
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Resource 




DEPARTMENT 

Object 

i r 





Manpower 

Database 




Figure C-6: Add, Modify, and Delete DEPARTMENT Object 
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Manpower 

Database 




Figure C-7 : Add, Modify, and Delete DIVISION Object 
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(A) 






Figure C-8: Update OBILLET and EBILLET Objects 
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Manpower 

Database 




Figure C-9: Add, Modify, and Delete OBILLET Object 
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Manpower 

Database 




Figure C-10: Add, Modify, and Delete EBILLET Object 
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LEGEND 

ODCR = Officer Distribution Control Report 
PCS = Permanent Change of Station 



Figure C-ll: 



Update OFFICER Objects 
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Manpower 

Database 




LEGEND 

ODCR = Officer Distribution Control Report 
PCS = Permanent Change of Station 



Figure C-12: Add, Modify, and Delete OFFICER Object 
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LEGEND 



EDVR = Enlisted Distribution Verification Report 
PCS = Permanent Change of Station 
AN, SN, FN = Airman, Seaman, Fireman 



Figure C-13: Update ENLISTED Objects 
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Manpower 

Database 




LEQENQ 

EDVR - Enlisted Distribution Verification Report 
PCS = Permanent Change of Station 
AN, SN, FN - Airman, Seaman, Fireman 



Figure C-14: Add, Modify, and Delete ENLISTED Objects 
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LEGEND 

(1) Grade/Paygrade Status Report 

(2) Designator/Rating Status Report 

(3) Officer Manning Report 

(4) Officer Status Report 

(5) Department Manning Report 



(6) Division Manning Report 

(7) Department Status Report 

(8) Division Status Report 

(9) Personnel Gains/Losses Report 



Figure C-15: Create Reports Process 
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Figure C-16: Create Enlisted Reports 
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Figure C-17: Create Enlisted Manning Reports 
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Figure C- 18 : 



Create Enlisted Status Reports 
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Database 




Figure C-19: Create Officer Reports 
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Object 



Figure C-20: Create Other Status Reports 
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Figure C-21: Create Other Reports 
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APPENDIX D: SAMPLE FORMS AND REPORTS 



ENLISTED PERSONNEL DATA INPUT/CHANGE FORM 

Last Name First Name Ml 

Rating Paygrade Rate 

PNEC SNEC SSN PRD~ TIR~ TIS 

Comments (Colaterial Duties, Watch Section, Qualifications) 

(Enter RATING and PAYGRADE; system will enter RATE) 

BILLET ASSIGNMENT 

Department 
BSC 

BILLET ASSIGNMENT 

Department Division 

BSC Billet Title 

Do you wish to add, modify or delete another Enlisted Record? (A/M/D/NO) 

Figure D-l: Enlisted Personnel Data Input/Change Form 



Division 



Billet Title 
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ENLISTED BILLET DATA INPUT/CHANGE FORM 



Department 




Division 






BSC 


Billet Title 




Rating 


Paygrade 


Rate 


PNEC 


SNEC 






BA 


FY+1 


FY+2 FY-i-3 


FY+4 


FY+5 



(Enter RATING and PAYGRADE; system will enter RATE) 

Do you wish to add, modify, or delete an Enlisted Billet? (A/M/D/NO) 



Figure D 2: Enlisted Billet Data Input/Change Form 
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OFFICER PERSONNEL DATA INPUT/CHANGE FORM 



Last Name 


First Name Ml 


Grade Desig 


SSN PRD DCR 



Comments (Colaterial Duties, Watch Section, Qualifications) 

BILLET ASSIGNMENT 



Department 


Division 


BSC 

BILLET ASSIGNMENT 


Billet Title 


Department 


Division 


BSC 


Billet Title 



Do you wish to add, modify, or delete another Officer Record? (A/M/D/NO) 

Figure D-3: Officer Personnel Data Input/Change Form 
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OFFICER BILLET DATA INPUT/CHANGE FORM 



Department 



Division 



BSC Billet Title 



Grade Desig 



BA FY+1 FY+2 FY+3 FY+4 FY+5 



Do you wish to add, modify, or delete an Officer Billet? (A/M/D/NO) 



Figure D-4 : Officer Billet Data Input/Change Form 
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DEPARTMENT MANNING REPORT 



REPORT DATE 



DEPARTMENT: OPERATIONS 



BSC 


BILLET 


RATE 


PNEC 




TITLE 




SNEC 


30060 


Signalman 


SMI 




30070 


Signalman 


SM2 





DEPARTMENT: OPERATIONS 



55060 


Boatsmate 


BM1 




55070 


BM Basic 


SN 


9700 



DIVISION MANNING REPORT 

DEPARTMENT: OPERATIONS 



BSC 


BILLET 


RATE 


PNEC 




TITLE 




SNEC 


30060 


Signalman 


SMI 




30070 


Signalman 


SM2 





DIVISION: F DIVISION 



BA 


NAME 


RATE 


PNEC 

SNEC 


PRD/ 

EAOS 


1 


Jones, R. 


SMI 




9203/ 

9406 


2 


Petty, T. 


SM2 




9212/ 

9406 




Kart, E. 


SM3 




9303/ 

9406 



DIVISION: DECK DIVISION 



1 


Kennedy, C 


BM1 


9101/ 

9203 


28 


Jones, L 


BMSN 


9212/ 

9112 




Cathcart, M. 


SN 


9303/ 

9406 



REPORT DATE 



DIVISION: F DIVISION 



BA 


NAME 


RATE 


PNEC 

SNEC 


PRD/ 

EAOS 


1 


Jones, R. 


SMI 




9203/ 

9406 


2 


Petty, T. 


SM2 




921 2/ 
9112 



Figure D-5: Department/Division Manning Report 
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OFFICER MANNING REPORT REPORT DATE 

DEPARTMENT: OPERATIONS 



BSC 


BILLET 

TITLE 


GRADE/DESIG 


BA 


NAME 


GRADE/DESIG 


PRD 


30060 


OPS Officer 


LCDR 


1300 


1 


Jones, R. 


LCDR 


1300 


9406 




DIVISION: SCHEDULES 














30070 


Scheduler 


LT 


1300 


2 


Petty, T. 


LTJG 


1305 


9212 




DIVISION: DET6 
















30080 


DETOIC 


LCDR 


1300 


1 


Kart, E. 


LCDR 


1300 


9303 


DEPARTMENT: ADMINISTRATION 












55070 


ADMIN Officer 


LCDR 


1300 


1 


Jones, L. 


LCDR 


1300 


9212 


55075 


Legal Officer 


LT 


1 100 


1 


Cathcart, M. 

★ 

* 


LT 


1 1 05 


9303 












★ 









Figure D-6: Officer Manning Report 
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GAINS / LOSSES REPORT 



REPORT DATE 



GAINS 


NAME 


GRADE 

RATE 


DESIG 

PNEC 


EDA 


Jones, R. 


LT 


1300 


9002 


Smith, M. 


ENS 


1100 


9010 


Carry, D. 


ADCS 




9008 


LOSSES 


NAME 


GRADE 

RATE 


DESIG 

PNEC 


PRD 


Calloway, T. 


CDR 


1300 


9003 


Mello, C. 


LTJG 


1310 


9005 



Figure D-7: Gains/Losses Report 
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DEPARTMENT STATUS REPORT 



REPORT DATE 



DEPARTMENT: MAINTENANCE 

DIVISION: MAINT/PROD CTL 



BSC 


BILLET 

TITLE 


RATE 


PNEC 

SNEC 


BA 


16050 


Maint Coord 


ATCM 


8300 


1 


16060 


Maint Prod 


ATCS 




2 



COB POB1 POB2 POB3 POB4 

11111 
2 2 3 3 2 



DIVISION: QUALITY ASSURANCE 



18060 QAREP 
18070 QAREP 



ADI 8318 2 

AMH1 8380 2 



112 2 2 
3 3 3 2 2 



DIVISION: MATERIAL CONTROL 

19060 MTLCLK AK1 3 3 



2 2 2 



DIVISION STATUS REPORT REPORT DATE 



DEPARTMENT: MAINTENANCE 

DIVISION: POWER PLANTS] 



BA 


BILLET 

TITLE 


RATE 


PNEC 

SNEC 


BA 


OOB 


POB1 


POB2 


POB3 


POB4 


22070 


P/P Repairman 


AD2 


8380 


6 


5 


5 


5 


5 


4 


22080 


P/P Repairman 


AD3 


8318 


3 


4 


4 


4 


3 


3 



Figure D-8: Department/Division Status Report 
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OFFICER 


STATUS REPORT 








REPORT 


DATE 




DEPARTMENT: SAFETY 


















BSC 


BILLET 


GRADE/DESIG 


BA 


COB 


POB1 


POB2 


POB3 


POB4 


14010 


AV Safety 


LT 


1311 


1 


1 


1 


1 


1 


0 


14020 


AV Safety Asst 


LTJG 


1311 


1 


1 


1 


1 


1 


1 


14030 


AV Safety Asst 


ENS 


1321 


1 


0 


0 


1 


1 


1 



DEPARTMENT: MAINTENANCE 

DIVISION: MAINT/PROD CTL 

16010 A/CORGMNT ENS 1311 1 1 1 1 1 1 



DIVISION: MAINT ADMIN 



17010 A/CORGMNT ENS 1311 



1 



Figure D-9: Officer Status Report 
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GRADE/PAYGRADE STATUS REPORT REPORT DATE 

COMMAND SUMMARY 



OFFICER 



GRADE 


BA 


COB 


% 


POB1 


POB2 


POB3 


POB4 


POB5 


POB6 


POB7 


CAPT 


1 


1 


1 00 


1 


1 


2 


1 


1 


1 


1 


CDR 


3 


3 


1 00 


3 


3 


3 


3 


3 


3 


3 


LCDR 


8 


8 


1 00 


8 


8 


8 


8 


8 


7 


7 


LT 


20 


18 


92 


21 


21 


20 


20 


20 


22 


22 


LTJG 


1 5 


12 


80 


12 


12 


13 


13 


13 


13 


13 


ENS 


8 


6 


75 


6 


6 


6 


6 


6 


6 


6 


CWO 2-4 


2 


2 


1 00 


2 


2 


2 


2 


2 


2 


2 


TOTAL 


57 


50 


87.7 


53 


53 


54 


53 


53 


54 


52 


enlisted 


PAYGRADE 


BA 


OOB 


% 


POB1 


POB2 


POB3 


POB4 


POB5 


POB6 


P037 


E9 


1 


1 


1 00 


1 


1 


2 


1 


1 


1 


1 


E8 


4 


3 


75 


3 


3 


3 


3 


3 


3 


3 


E7 


10 


12 


120 


8 


8 


8 


8 


8 


7 


7 


E6 


24 


20 


83.3 


21 


21 


20 


20 


20 


22 


20 


E5 


40 


35 


87.5 


32 


32 


33 


33 


33 


33 


33 


E4 


50 


42 


84 


6 


6 


6 


6 


6 


6 


6 


El-3 


67 


55 


82 


52 


52 


52 


52 


52 


52 


52 


TOTAL 


1 96 


1 68 


85.7 


123 


123 


124 


123 


123 


124 


122 



Figure D-10: Grade/Paygrade Status Report 
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DESIGNATOR / RATING STATUS REPORT REPORT DATE 



DESIG 


CA D T COR 
BA/COB 


LCDR 


LT 


LTJG 


BIS 


0WO4 CW03 0WO2 TOTAL 


1310 


1 /I 


2/2 


3/2 






6/5 


1320 








6/7 




6/7 


131 1 












0/0 


1 000 








1 /I 




1 /I 


1 1 00 








2/1 


1 /I 


3/2 


1520 












0/0 


TOTAL 


1 /I 


2/2 


3/2 


9/9 


1 /I 


1 6/1 5 



RATING 


PNEC E9 
SNEC 


E8 


E7 


E6 


E5 


E4 


El -3 


TOTAL 


AD 


6411 






1 / 2 


1 /I 


1 /I 


1/1 


4/5 


AD 


6418 






2/1 




2/2 




4/3 


AD 


6422 






4/3 


5/5 


7/6 


11/11 


27/25 


AD 


8318 




2/2 


3/4 




2/2 




7/8 


AD 


8300 






1 /I 


2/2 


4/4 


3/3 


10/10 



TOTAL ' 2/2 1 1/1 1 8/8 1 6/15 15/15 52/51 



Figure D-ll: Designator/Rating Status Report 
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APPENDIX E 



RELATIONAL DIAGRAM 




Figure E-l: Relational Diagram 
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APPENDIX F: RELATION DEFINITIONS 



A. RELATION AND KEY DEFINITIONS 

1. OFFICER (SSN, Name, Grade, Designator, PRD, Date of 

Rank, DName, DivName) 

Key: SSN 

Foreign Keys: DName, DivName) 

2. ENLISTED (SSN, Name, Rating, Paygrade, Rate, PNEC, 

SNEC, PRD, EAOS, Date of Rate, Time in Service, 
DName, DivName) 

Key: SSN 

Foreign Keys: DName, DivName) 

3. DEPARTMENT (DName) 

Key: DName 

4. DIVISION (DivName, DName) 

Key: DivName 

Foreign Key: DName 

5. OBILLET (BSC, Billet Title, Grade, Designator, 

BA ( CUR ) , BA(FYl) , BA(FY2) , BA (FY3 ) , BA (FY4 ) , 
DName, DivName) 

Key: BSC 

Foreign Keys: DName, DivName 

6. EBILLET (BSC, Billet Title, Rating, Paygrade, Rate, 

PNEC, SNEC, BA, DName, DivName) 
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Key: BSC 

Foreign Keys: DName, DivName 

7. OASSIGN (BSC, SSN) 

Key: BSC, SSN 

8. EASSIGN (BSC, SSN) 

Key: BSC, SSN 

9. COLDUTY (SSN, Collaterial Duties) 

Key: SSN, Collaterial Duty 

B. DOMAIN DEFINITIONS 



1. 


BA 


IN 


NUM ( 4 ) 




2. 


Billet Title 


IN 


CHAR (20) 




3 . 


BSC 


IN 


NUM (5) 




4. 


COB 


IN 


NUM (4) 




5. 


Date 


IN 


YYMMDD, YY 


= 00-99; 








MM = 1-12; 


DD = 1-31 


6. 


Date of Rank 


IN 


YYMMDD, YY 


= 00-30; 








MM = 0-11; 


DD = 0-30 


7 . 


Date of Rate 


IN 


YYMMDD, YY 


= 00-30; 








MM = 0-11; 


DD = 0-30 


8. 


Designator 


IN 


NUM (4) 




9. 


DivName 


IN 


CHAR (15) 




10. 


DName 


IN 


CHAR (15) 
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11. 


Grade 


IN 


CHAR (4); FADM, ADM, VADM, 
RDMU, RAML, CAPT, CDR, 
LCDR, LT, LTJG, ENS , CW04 , 
CW03, or CW02 


12 . 


Name 


IN 


CHAR (40) 


13. 


NEC 


IN 


NUM ( 4 ) 


14 . 


Paygrade 


IN 


CHAR (5)/ E9 , E8 , E7 , E6, 
E5 , E4 , E1-E3 


15. 


PNEC 


IN 


NUM (4) 


16. 


POB 


IN 


NUM (4) 


17 . 


PRD 


IN 


NUM ( 5 ) ; YYMM, A = "A" or 
blank, YY = 00-99, 

MM = 01-12 


18 . 


Rate 


IN 


Char (5) 


19 . 


Rating 


IN 


CHAR ( 5 ) ; XXXZZ, XXX is any 
enlisted rate and ZZ is one 
of: 1, 2, 3, C, CS, CM 


20. 


SNEC 


IN 


NUM (4) 


21. 


SSN 


IN 


NUM (9) 
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APPENDIX 6: UPDATE, DISPLAY, AND CONTROL MECHANISMS 



A. UPDATE MECHANISMS 

1. OBILLET Update Mechanisms 

a. Add new OBILLET data 

(1) Inputs 

- List of authorized billets from OPNAV 
1000/2 or Notification Letter from the 
appropriate Resource Sponsor. 

(2) Outputs 

- New OBILLET object instance in database. 

(3) Processing notes 

- Data imported enmasse when creating 
database . 

(4) Volume 

- 10 to 500 billets input when creating 
database . 

- Usually less than one per year. 

(5) Frequency 

- Once per year. 

b. Edit data in OBILLET 
1) Inputs 

- OBILLET object instance from database 
(including DEPARTMENT properties) . 
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- OBILLET change data from OPNAV 1000/2 or 
Notification Letter from the appropriate 
Resource Sponsor. 

( 2 ) Outputs 

- Modified object instance to database. 

- Confirmation message on screen. 

(3) Processing notes 

- This function changes all OBILLET data. 

(4) Volume 

- Unpredictable, but changes rarely occur. 

(5) Frequency 

- Once per year, 
c. Delete OBILLET data 

(1) Inputs 

- List of billets to delete from OPNAV 
1000/2 or Notification Letter from the 
appropriate Resource Sponsor. 

- OBILLET object instance from database. 

( 2 ) Outputs 

- Confirmation message on screen. 

(3) Processing notes 

- Backup of existing object should be made 
prior to deletion. 

(4) Volume 

- Unpredictable, but deletions rarely 
occur . 
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(5) Frequency 

- Less than once per year. 

2. EBILLET Update Mechanisms 

a. Add new EBILLET data 

(1) Inputs 

- List of authorized billets from OPNAV 
1000/2 or Notification Letter from the 
appropriate Resource Sponsor. 

( 2 ) Outputs 

- New EBILLET object instance in database. 

(3) Processing notes 

- Data imported enmasse when creating 
database. 

(4) Volume 

- 20 to 5000 billets input when creating 
database . 

- Usually less than one per year. 

(5) Frequency 

- Once per year. 

b. Edit data in EBILLET 
(1) Inputs 

- EBILLET object instance from database 
(including DEPARTMENT properties). 

- EBILLET change data from OPNAV 1000/2 or 
Notification Letter from the appropriate 
Resource Sponsor. 
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( 2 ) 



Outputs 

- Modified object instance to database. 

- Confirmation message on screen. 

(3) Processing notes 

- This function changes all EBILLET data. 

(4) Volume 

- Unpredictable, but changes rarely occur. 

(5) Frequency 

- Once per year, 
c. Delete EBILLET data 

(1) Inputs 

- List of billets to delete from OPNAV 
1000/2 or Notification Letter from the 
appropriate Resource Sponsor. 

- EBILLET object instance from database. 

(2 ) Outputs 

- Confirmation message on screen. 

(3) Processing notes 

- Backup of existing object should be made 
prior to deletion. 

(4) Volume 

- Unpredictable, but deletions rarely 
occur. 

(5) Frequency 

- Less than once per year. 
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3. OFFICER Update Mechanisms 

a. Add new OFFICER data 

(1) Inputs 

- List of new officer personnel from ODCR 
PCS orders, or personnel input form from 
the Personnel Office. 

(2) Outputs 

- New OFFICER object instance in database 

(3) Processing notes 

- Data imported enmasse when creating 
database . 

(4) Volume 

- 10 to 500 billets input when creating 
database . 

- Five to 200 per year. 

(5) Frequency 

- Monthly. 

b. Edit data in OFFICER 
(1) Inputs 

- OFFICER object instance from database 
(including OBILLET properties) . 

- OFFICER change data from personnel data 
change form from the Personnel Office or 
the Executive Officer. 
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(2) Outputs 

- Modified object instance to database. 

- Confirmation message on screen. 

(3) Processing notes 

- This function changes all OFFICER data. 

(4) Volume 

- Ten officers per month. 

(5) Frequency 

- Monthly. 

c. Delete OFFICER data 

(1) Inputs 

- List of personnel to delete from the 
check out sheets received from the 
Department Head. 

- OFFICER object instance from database. 

(2) Outputs 

- Confirmation message on screen. 

(3) Processing notes 

- Backup of existing object should be made 
prior to deletion. 

(4) Volume 

- Zero to ten per month. 

(5) Frequency 

- Monthly. 

4 . ENLISTED Update Mechanisms 
a. Add new ENLISTED data 
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( 1 ) 



Inputs 

- List of new enlisted personnel from EDVR 
and PCS orders. 

( 2 ) Outputs 

- New ENLISTED object instance in database. 

(3) Processing notes 

- Data imported enmasse when creating 
database. 

(4) Volume 

- 50 to 5000 billets input when creating 
database. 

- Ten to 1500 per year. 

(5) Frequency 

- Weekly. 

Edit data in ENLISTED 

(1) Inputs 

- ENLISTED object instance from database 
(including EBILLET properties) . 

- ENLISTED change data from personnel data 
change form from the Personnel Office or 
the Department Head. 

( 2 ) Outputs 

- Modified object instance to database. 

- Confirmation message on screen. 

Processing notes 

- This function changes all ENLISTED data. 



( 3 ) 



(4) Volume 

- 100 enlisted personnel per month. 

(5) Frequency 

- Weekly. 

c. Delete ENLISTED data 

(1) Inputs 

- List of personnel to delete from the 
check out sheets received from the 
Department Head. 

- ENLISTED object instance from database. 

(2) Outputs 

- Confirmation message on screen. 

(3) Processing notes 

- Backup of existing object should be made 
prior to deletion. 

(4) Volume 

- Zero to 100 per month. 

(5) Frequency 

- Weekly. 

5. DEPARTMENT Update Mechanisms 
a. Add new DEPARTMENT data 
(1) Inputs 

- New DEPARTMENT list from OPNAV 1000/2 or 
Notification Letter from the appropriate 
Resource Sponsor. 
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(2) Outputs 

- New DEPARTMENT object instance in 
database. 

(3) Processing notes 

- Data imported enmasse when creating 
database . 

(4) Volume 

- Four to ten departments input when 
creating database. 

- Less than one per year. 

(5) Frequency 

- Less than annually, 
b. Edit data in DEPARTMENT 

(1) Inputs 

- DEPARTMENT object instance from database 
(including DIVISION properties). 

- DEPARTMENT change data from OPNAV 1000/2 
or Notification Letter from the appropriate 
Resource Sponsor. 

(2) Outputs 

- Modified object instance to database. 

- Confirmation message on screen. 

(3) Processing notes 

- This function changes all DEPARTMENT 
data. 
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(4) Volume 

- Less than one per year. 

(5) Frequency 

- Less than annually, 
c. Delete DEPARTMENT data 

(1) Inputs 

- List of departments to delete from OPNAV 
1000/2 or Notification Letter from the 
appropriate Resource Sponsor. 

- DEPARTMENT object instance from database. 

(2) Outputs 

- Confirmation message on screen. 

(3) Processing notes 

- Backup of existing object should be made 
prior to deletion. 

(4) Volume 

- Less than one per year. 

(5) Frequency 

- Less than annually. 

6. DIVISION Update Mechanisms 

a. Add new DIVISION data 
(1) Inputs 

- New DIVISION list from OPNAV 1000/2 or 
Notification Letter from the appropriate 
Resource Sponsor. 
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(2) Outputs 

- New DIVISION object instance in database. 

(3) Processing notes 

- Data imported enmasse when creating 
database. 

(4) Volume 

- Five to 50 divisions input when creating 
database. 

- Less than one per year. 

(5) Frequency 

- Less than annually, 
b. Edit data in DIVISION 

(1) Inputs 

- DIVISION object instance from database 
(including OBILLET and EBILLET properties). 

- DIVISION change data from OPNAV 1000/2 or 
Notification Letter from the appropriate 
Resource Sponsor. 

( 2 ) Outputs 

- Modified object instance to database. 

- Confirmation message on screen. 

(3) Processing notes 

- This function changes all DIVISION data. 

(4) Volume 

- Less than one per year. 
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(5) Frequency 

- Less than annually, 
c. Delete DIVISION data 

(1) Inputs 

- List of divisions to delete from OPNAV 
1000/2 or Notification Letter from the 
appropriate Resource Sponsor. 

- DIVISION object instance from database. 

(2) Outputs 

- Confirmation message on screen. 

(3) Processing notes 

- Backup of existing object should be made 
prior to deletion. 

(4) Volume 

- Less than one per year. 

(5) Frequency 

- Less than annually. 

B. DISPLAY MECHANISMS 

1. OFFICER Display Mechanisms 
a. Query on OFFICER 

(1) Output Description 

- Form showing all data for an Officer. 

(2) Source Data 

- OFFICER object. 
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- DEPARTMENT object. 

- Officer name or SSN keyed in by user. 

(3) Processing Notes. 

- Used by manpower analyst, or other 
authorized user. 

(4) Volume 

- Five per week. 

(5) Frequency 

- Daily. 

b. Officer Manning Report 

(1) Output Description 

- Report showing Officer billets authorized 
and the Commissioned Officers assigned to 
them. 

(2) Source Data 

- OFFICER object. 

- DEPARTMENT object. 

(3) Processing Notes. 

- Report produced upon request from user. 

(4) Volume 

- One for each department head, including 
Executive department. 

(5) Frequency 

- Monthly. 
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c. Officer Status Report 

(1) Output Description 

- Report showing Officer billets authorized 
and the number of personnel assigned to 
them. 

(2) Source Data 

- OFFICER object. 

- DEPARTMENT object. 

(3) Processing Notes. 

- Report produced upon request from user. 

(4) Volume 

- One for each department head, including 
Executive department. 

(5) Frequency 

- Monthly 

2. ENLISTED Display Mechanisms 
a. Query on ENLISTED 

(1) Output Description 

- Form showing all data for an Enlisted 
member . 

(2) Source Data 

- ENLISTED object. 

- DEPARTMENT object. 

- Enlisted member's name or SSN keyed in by 
user . 
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(3) Processing Notes. 

- Used by manpower analyst, or other 
authorized user. 

(4) Volume 

- Five per week per department. 

(5) Frequency 

- Daily. 

b. Department/Division Manning Report 

(1) Output Description 

- Report showing Enlisted billets 
authorized and the personnel assigned to 
them. 

(2) Source Data 

- ENLISTED object. 

- DEPARTMENT or DIVISION object. 

(3) Processing Notes. 

- Report produced upon request from user. 

(4) Volume 

- One for each department head, including 
Executive department. 

(5) Frequency 

- Monthly. 
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c. Department/Division Status Report 

(1) Output Description 

- Report showing Enlisted billets 
authorized and the number of personnel 
assigned to them. 

(2) Source Data 

- ENLISTED object. 

- DEPARTMENT or DIVISION object. 

(3) Processing Notes. 

- Report produced upon request from user. 

(4) Volume 

- One for each department head, including 
Executive department. 

(5) Frequency 

- Monthly 

3. Combined OFFICER/ENLISTED Display Mechanisms 
a. Designator/Rating Status Report 

(1) Output Description 

- Report showing the quantity of billets 
authorized by designator and rating, and 
the number of personnel assigned within 
each . 

(2) Source Data 

- OFFICER object. 

- ENLISTED object. 

- DEPARTMENT or DIVISION object. 
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(3) Processing Notes. 

- Report produced upon request from user. 

(4) Volume 

- One for each department, including 
Executive department. 

(5) Frequency 

- Monthly. 

b. Paygrade Status Report 

(1) Output Description 

- Report showing the quantity of billets 
authorized by paygrade and the number of 
personnel assigned within each paygrade. 

(2) Source Data 

- OFFICER object. 

- ENLISTED object. 

- DEPARTMENT or DIVISION object. 

(3) Processing Notes. 

- Report produced upon request from user. 

(4) Volume 

- One for each department head, including 
Executive department. 

(5) Frequency 

- Monthly. 
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c. Personnel Gains/Losses Report 



(1) Output Description 

- Report showing the personnel ordered to 
the command but not yet received and 
personnel whose PRD is within three months 
of the report date. 

(2) Source Data 

- OFFICER object. 

- ENLISTED object. 

(3) Processing Notes. 

- Report produced upon request from user. 

(4) Volume 

- One for each department head, including 
Executive department. 

(5) Frequency 

- Monthly 

C. CONTROL MECHANISMS 

1. System Control Mechanisms 

a. Provide password system to ensure that only 
authorized users can access for viewing, 
editing, or deleting data. 

b. Provide verification system to ensure that the 
authorized users have the opportunity to verify 
data prior to an instance of any object being 
stored in the database. 
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c. Provide verification system to ensure that the 
authorized users have the opportunity to verify 
data prior to an instance of any object being 
deleted from the database. 

d. Provide security controls to ensure that data in 
the database cannot be altered from the Reports 
application . 

2. Object Control Mechanisms 

a. Provide a set of tables to ensure that only 
authorized data values for Rating, Rate, 
Paygrade, PNEC/SNEC, Grade, Designator, Billet 
Sequence Code, Department and Division Name are 
entered into data fields prior to an instance of 
an object being stored in the database. 

b. Provide verification system to ensure that 
mandatory fields have values entered prior to an 
instance of an object being stored in the 
database . 



127 



APPENDIX H: MENU HIERARCHY 




Figure H-l: Menu Tree 
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WELCOME TO 



AMA/PMS 
MAIN MENU 



1 . Manpower 

2. Reports 

3. Exit to OS 



Enter the number of your selection 



Figure H-2: Main Menu 
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AMA/PMS 



MANPOWER MENU 



1 . Billet Data 

2. Personnel Data 

3. Return to Main Menu 



Enter the number of your selection 



Figure H-3 : Manpower Menu 
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AMA/PMS 



REPORTS MENU 

1. Gains/Losses Report 

2. Manpower Report 

3. Status Report 

4. Ad Hoc Queries 

5. Return to Main Menu 



Enter the number of your selection 



Figure H-4: Reports Menu 
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AMA/PMS 



BILLET DATA MENU 

1 . Add New Billet 

2. Edit Billet Data 

3. Delete Billet 

4. Personnel Data Menu 

5. Reports Menu 

6. Return to Manpower Menu 



Enter the number of your selection 



Figure H-5: Billet Data Menu 
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AMA/PMS 



PERSONNEL DATA MENU 

1 . Add New Personnel 

2. Edit Personnel Data 

3. Delete Personnel 

4. Billet Data Menu 

5. Reports Menu 

6. Return to Manpower Menu 



Enter the number of your selection 



Figure H-6: Personnel Data Menu 
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AMA/PMS 



MANPOWER REPORTS MENU 

1 . Department 

2. Division 

3. Officer 

4. Status Reports Menu 

5. Manpower Menu 

6. Return to Reports Menu 



Enter the number of your selection 



Figure H-7 : Manpower Reports Menu 
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AMA/PMS 



STATUS REPORTS MENU 

1 . Department 

2. Division 

3. Designator / Rating 

4. Grade/Paygrade 

5. Officer 

6. Manpower Reports Menu 

7. Manpower Menu 

8. Return to Reports Menu 



Enter the number of your selection 



Figure H-8: Status Reports Menu 
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AMA/PMS 



BILLET TYPE MENU 



1 . Officer 

2. Enlisted 

3. Return to Billet Data Menu 



Enter the number of your selection 



Figure H-9 : Billet Type Menu 
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AMA/PMS 



BILLET DISPLAY MENU 



1 . By Department 

2. By Division 

3. By BSC 

4. Return to Billet Data Menu 



Enter the number of your selection 



Figure H-10: Billet Display Menu 
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RECORD TYPE MENU 



1 . Officer 

2. Enlisted 

3. Return to Personnel Data Menu 



Enter the number of your selection 



Figure H-ll: Record Type Menu 



138 



139 






APPENDIX Is MEND LOGIC (PSEUDO CODE) 



A. MAIN MENU 
Begin (*module*) 

Case menu choice of: 

1: Get MANPOWER MENU 

2: Get REPORTS MENU 

End (*module*) 

B . MANPOWER MENU 
Begin (*module*) 

Case menu choice of: 



1: Get BILLET DATA MENU 

2: Get PERSONNEL DATA MENU 

3: Get MAIN MENU 

End (*module*) 

C. REPORTS MENU 

Begin (*module*) 

Case menu choice of: 

1: Get MANPOWER REPORTS MENU 

2: Get STATUS REPORTS MENU 

3: Get Gains/Losses Report ( *procedure call*) 

4: Get MAIN MENU 

End (*module*) 
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D. 



BILLET DATA MENU 



Begin (*module*) 

Case menu choice of : 

1: Get BILLET TYPE MENU 

2: Get BILLET DISPLAY MENU 

3: Get BILLET DISPLAY MENU 

4: Get REPORTS MENU 

5: Get MANPOWER MENU 

End (*module*) 

E. PERSONNEL DATA MENU 

Begin (*module*) 

Case menu choice of: 

1: Get RECORD TYPE MENU 

2: Get Edit Personnel Data (*procedure call*) 

(*edit function handled by DBMS*) 

3: Get Delete Personnel Data (*procedure call*) 

(♦delete function handled by DBMS*) 

4: Get REPORTS MENU 

5: Get MANPOWER MENU 

End (*module*) 

F. MANPOWER REPORTS MENU 
Begin (*module*) 

Case menu choice of : 

1: Get Department Manning Report (*procedure 

call*) 

2: Get Division Manning Report (*procedure call*) 
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3: Get Officer Manning Report (*procedure call*) 

4: Get MAIN MENU 

5: Get REPORTS MENU 

End (*module*) 

G. STATUS REPORTS MENU 
Begin (*module*) 

Case menu choice of : 

1: Get Department Status Report (‘procedure 

call*) 

2: Get Division Status Report (‘procedure call*) 

3: Get Designator/Rate Status Report (‘procedure 

call*) 

4: Get Paygrade Status Report (‘procedure call*) 

5: Get Officer Status Report (‘procedure call*) 

6: Get MANPOWER MENU 

7: Get REPORTS MENU 

End ( ‘module* ) 

H. BILLET TYPE MENU 
Begin (‘module*) 

Case menu choice of : 

1: Get Add Officer Billet (‘procedure call*) 

(*add function handled by DBMS*) 

2: Get Add Enlisted Billet (‘procedure call*) 

(*add function handled by DBMS*) 

3: Get BILLET DATA MENU 

End (*module*) 
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I. BILLET DISPLAY MENU 

Begin (*module*) (*display function handled by DBMS*) 
Case menu choice of: 

1: Get Display Department Billets (*procedure 

call* ) 

2: Get Display Division Billets ( *procedure 

call*) 

3: Get Display Billet By BSC (*procedure call*) 

4: Get BILLET DISPLAY MENU 

End (*module*) 

J. RECORD TYPE MENU 
Begin (*module*) 

Case menu choice of: 

1: Get New Officer Record (*procedure call*) 

2: Get New Enlisted Record (*procedure call*) 

3: Get PERSONNEL DATA MENU 

End (*module*) 

K. REPORT GENERATION PROCEDURES 

1. Department/Division Manning Report 

a. Display data by Department then by Division. 

b. Records/Fields used: 

1) EBILLET/BSC, Billet Title, BA, Rate, PNEC, 
SNEC, DName, DivName 

2) ENLISTED/BSC, Name, Rate, PNEC, SNEC, PRD, 
EAOS 

c. Sort EBILLET records by DName, DivName . 
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d. For each BSC in EBILLET, compare and match 
ENLISTED records to EBILLET records by keying on 
BSC . 

e. Print data per report format in Appendix D. 

2. Department/Division Status Report 

a. Display data by Department then by Division. 

b. Records/Fields used: 

1) EBILLET/BSC , Billet Title, BA Rate, PNEC, 

SNEC , DName, DivName 

2) ENLISTED/BSC, PRD, EAOS 

c. Sort EBILLET records by DName . DivName . 

d. For each BSC in EBILLET, compare and match 
ENLISTED records to EBILLET records by keying on 
BSC . 

f. Using ENLISTED records calculate number of 
personnel on board for each BSC for the current 
month and for each of the next four (4) months. 

(For each BSC in ENLISTED record, if EAOS < PRD . use 
EAOS to determine projected on board; else use PRD.) 

g. Print data per report format in Appendix D. 

3. Officer Manning Report 

a. Display data by Department then by Division. 

b. Records/Fields used: 

1) OBILLET/BSC, Billet Title, BA, Grade, 
Designator, DName, DivName 

2) OFFICER/BSC, Name, Grade, Designator, PRD 
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c. Sort OBILLET records by DName . DivName . 

d. For each BSC in OBILLET, compare and match 
OFFICER records to OBILLET records by keying on BSC . 

e. Print data per report format in Appendix D. 

4. Officer Status Report 

a. Display data by Department then by Division. 

b. Records/Fields used: 

1) OBILLET/BSC, Billet Title, Grade, Designator, 
BA, DName, DivName 

2) OFFICER/BSC, PRD 

c. Sort records on BSC . 

d. For each BSC in OBILLET, determine the number of 
OFFICERS assigned against it for current month and 
each of the next four (4) months. 

e. Print data per report format in Appendix D. 

5. Grade/Paygrade Status Report 

a. Records/Fields used: 

1) OBILLET/Grade, BA 

2) OFFICER/Grade, PRD 

3) EBILLET/Paygrade, BA 

4) ENLISTED/Paygrade , PRD, EAOS 

b. Sort OBILLET and OFFICER records on Grade. 

c. Sort EBILLET and ENLISTED records on Paygrade. 

d. Calculate - OFFICER PAYGRADE STATUS REPORT 

1) Using OBILLET records, count number of BA for 
each Grade. 
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2) Using OFFICER records, count number of each 
Grade currently assigned. 

3) Calculate percent of BA currently filled for 
each Grade (COB/BA) . 

4) Using the PRD field of OFFICER record, 
calculate the number of each Grade on board for 
the current month and for each of the next seven 
(7) months. 

e. Calculate - ENLISTED PAYGRADE STATUS REPORT 

1) Using EBILLET records, count number of BA for 
each Pavorade . 

2) Using ENLISTED records, count number of each 
Pavorade currently assigned. 

3) Calculate percent of BA currently filled for 
each Pavorade (COB/BA) . 

4) Using the PRD or EAOS field of ENLISTED 
record, calculate the number of each Pavorade on 
board for the current month and for each of the 
next seven (7) months. (For each ENLISTED 
record, if EAOS < PRD . use EAOS to determine 
projected on board; else use PRD . 

f. Print data per report format in Appendix D. 

6. Designator/Rating Status Report 

a. Display data by Designator and Rating 

b. Records/Fields used: 

1) OBILLET/Grade, BA, Designator 
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2) OFFICER/Grade, Designator 

3) EBILLET/BA, PNEC, SNEC, Rating, Paygrade 

4) ENLISTED/PNEC, Rate 

c. Sort OBILLET and OFFICER records on Designator. 

d. Sort EBILLET and ENLISTED records on Rate, then 
by PNEC (if one is assigned) . 

e. Calculate - DESIGNATOR STATUS REPORT 

1) Using OBILLET records: For each Designator in 
OBILLET, count number of BA in each Grade. 

2) Using OFFICER records: For each Designator in 
OFFICER, count number of personnel on board in 
each Grade . 

f. Calculate - RATING STATUS REPORT 

1) Using EBILLET records: 

a) For each Rating in EBILLET, count number 
of BA for each Paygrade ♦ 

b) Subdivide each Rating by PNEC if one is 
assigned. 

2) Using ENLISTED records: 

a) For each Rate in ENLISTED, count number 
of personnel currently on board. 

b) Subdivide each Rate by PNEC if one is 
assigned. 

g. Print data per report format in Appendix D. 
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7. Gains/Losses Report 

a. Records/Fields used: 

1) OFFICER/Name, Grade, Designator, PRD 

2) ENLISTED/Name , Rate, PNEC, PRD, EAOS 

b. Sort records by PRD. 

c. Calculate - GAINS REPORT 

1) Using OFFICER and ENLISTED records, identify 
those personnel who will be arriving at the 
activity within the next six (6) months. (This 
date will be reflected in the PRD field with an 
"A" as the first digit.) 
d) Calculate - LOSSES REPORT 

1) Using OFFICER and ENLISTED records, identify 
those personnel who will be departing the 
activity within the next six (6) months. (For 
each ENLISTED record, if EAOS < PRD . use EAOS to 
determine projected on board; else use PRD.) 
e. Print data per report format in Appendix D. 
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